LB Booster
Programming >> Compatibility with LB4 >> Non-standard MID$
http://lbb.conforums.com/index.cgi?board=compatibility&action=display&num=1431077584
Non-standard MID$
Post by Richard Russell on May 8th, 2015, 09:33am

It has been brought to my attention that LB 4.04 behaves in a non-standard way if the second parameter of MID$ is zero or negative. For example:

Code:
    PRINT MID$("ABCDEF", 0, 4)
    PRINT MID$("ABCDEF", -1, 4)

outputs:

Code:
ABC
AB

This behaviour is undocumented and is not emulated in LBB. I do not know of any other dialect of BASIC which gives the same result.

Of course one should not normally pass an out-of-range value as the second parameter of MID$, but if done accidentally it could result in an incompatibility. In that event the following user-defined function, which emulates the LB behaviour, can be substituted:

Code:
FUNCTION LBMID$(a$, i, j)
    WHILE i < 1
      i = i + 1
      j = j - 1
    WEND
    IF j < 0 THEN j = 0
    LBMID$ = MID$(a$, i, j)
END FUNCTION

Richard.
Re: Non-standard MID$
Post by RNBW on May 8th, 2015, 11:28am

Interesting are the outputs from different Basics:
LB ABC
AB

LBB ABCD
Nothing

BBC ABCD
Nothing

QB64 ABC
AB

FreeBasic Nothing
Nothing

In fact, BBC Basic derived solutions are the only ones that come up with ABCD and Nothing. Personally, I don't think it should come up with anything, since 0 and a negative number do not physically appear as a position within the string. On that basis, only the FreeBasic compiler comes up with the correct answer. I would prefer to see an error, since 0 and negative numbers don't comply with the requirement of the function.
Re: Non-standard MID$
Post by Richard Russell on May 8th, 2015, 1:16pm

on May 8th, 2015, 11:28am, RNBW wrote:
I would prefer to see an error, since 0 and negative numbers don't comply with the requirement of the function.

QBasic reports an error.

But there's little point 'preferring' some behaviour different from what happens now. Every BASIC must continue to behave how it always has behaved, because any change could result in an incompatibility with existing programs.

In the specific case of BBC BASIC, all versions on all platforms - right back to the 6502 original in 1981 - have worked the same way. That's how it was designed by Acorn, and that's how it must remain.

Richard.
Re: Non-standard MID$
Post by RNBW 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.

Ray
Re: Non-standard MID$
Post by Richard Russell on May 8th, 2015, 4:00pm

on May 8th, 2015, 3:23pm, RNBW wrote:
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).

Richard.
Re: Non-standard MID$
Post by RNBW on May 8th, 2015, 4:59pm

'Nuff said!

Ray