Welcome Guest. Please Login or Register. Apr 1st, 2018, 04:32am
ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018. We apologize Conforums does not have any export functions to migrate data. Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.
Thank you Conforums members.
Speed up Liberty BASIC programs by up to ten times!
Compile Liberty BASIC programs to compact, standalone executables!
Overcome many of Liberty BASIC's bugs and limitations!
Re: Non-standard MID$
« Reply #3 on: May 8th, 2015, 3:23pm »
I agree, but I think that every BASIC should identify the fact that there is this peculiarity in the language. It could save users hours of head banging trying to sort out why their code is not working how they would expect it, but why anyone would want to enter 0 or a negative number into the MID$ function is beyond me.
There are similar peculiarities with LEFT$ and RIGHT$. BBC Basic and LBB print ABCDE for position of -1. The other BASICs I have access to show nothing. All the BASICs show nothing for position of 0.
However, thank you very much for bringing it to our attention. At least we know what happens in the particular circumstance.
why anyone would want to enter 0 or a negative number into the MID$ function is beyond me.
As I said, it's often an accident. In the case of the particular program which alerted me to the issue, I think it's unlikely that the author realised he was sometimes passing zero as the second parameter of MID$.
Sadly the 'trial and error' style of programming (in which the code isn't 'designed' but is fiddled with until things seem to 'work') is extremely popular, probably more so in BASIC than in other languages. Novices will often protest that it is the only method they can understand. Frankly it makes me quite cross!
Quote:
There are similar peculiarities with LEFT$ and RIGHT$. BBC Basic and LBB print ABCDE for position of -1.
I wouldn't call it a "peculiarity". BBC BASIC interprets all the parameters to the string-slicing functions as unsigned integers (on the basis that negative values are not meaningful as an index into a string, and that way the available range is doubled). So if you supply -1 that is actually interpreted as +255 (in early versions of BBC BASIC) or +65535 (in later versions) and then the behaviour makes perfect sense.
One doesn't always have the luxury of having a large enough integer range to represent -1 unambiguously. In an 8-bit register 0xFF hexadecimal is either -1 (signed) or +255 (unsigned) and in a 16-bit register 0xFFFF is either -1 (signed) or +65535 (unsigned).
Logged
