Bug in string handling in SMSQ/E

[NormanDunbar]

I'm using QPC2, the latest version in case that makes a difference.

If I define a string with some contents, then try to take a slice of that string where the start position is one less than the end position, I get the empty string. If the end position is 2 or more less than the start position, I get the "unacceptable array index" error message.

For example:

Code: Select all

a$ = "1234567890"
b$ = a$(4 to 3): REMark This works
REMark c$ = a$(4 to 2): REMark This fails with an error.

Turbo 415 happily compiles this and gives the same result as in S*Basic, the assignment to b$ is the empty string.

I found this because of a bug in Structured SuperBasic 2.7.2b (my changes recently) which was barfing on some lines of a bit of code I was working on, but not on other similar lines. Turned out to be a string slice where the start and end differed by 1 and the start was higher than the stop. I'm working on a fix even as I type.

Can anyone else see this error in S*Basic?


Cheers,
Norm.

[pjw]

Code: Select all

10 a$ = "1234567890"
20 b$ = a$(4 to 3): REMark This works
30 c$ = a$(4 to 2): REMark This fails with an error.

Neither Qdos JS nor Minerva accept line 30, so that seems to be normal behaviour. SMSQ/E seems just to catch the error before the program runs; the others fall over when they reach the line.

What I find a little incongruous, though is why line 20 is found to be acceptable. Surely, if line 30 is an error then so is line 20?

[NormanDunbar]

Thanks Per. I suggest therefore, that we have a bug!


Cheers,
Norm.

[XorA]

Code: Select all

10 a$ = "1234567890"
20 b$ = a$(4 to 3): REMark This works
30 c$ = a$(4 to 2): REMark This fails with an error.

Neither Qdos JS nor Minerva accept line 30, so that seems to be normal behaviour. SMSQ/E seems just to catch the error before the program runs; the others fall over when they reach the line.

What I find a little incongruous, though is why line 20 is found to be acceptable. Surely, if line 30 is an error then so is line 20?

Is it because line 20 is only only one char wide even if you are going the wrong direction?

[NormanDunbar]

Is it because line 20 is only only one char wide even if you are going the wrong direction?

Dunno!

Line 20 returns an empty string but only if (end_pos - start_pos) = -1. Any other negative difference between start_pos and end_pos results in the error message.

Cheers,
Norm.

[pjw]

"Legal" string slices could in theory be from 0 to LEN long. Since
LEN(string$(n to n)) = 1, then the only way to get to 0 is by
LEN(string$(n to n - 1))!

In other words: Its a "design philosophy", not a bug!

PRINT string$(1 to 0) also works!

PS:

<> .. SMSQ/E seems just to catch the error before the program runs; the others fall over when they reach the line.

I was mistaken. SMSQ/E behaves like the others.

[NormanDunbar]

I think that attempting to slice a string from the wrong end, as here, should either always return an empty string, or always return an error. This behaviour is not consistent.

I discovered this problem in SSB where it uses variables to slice the string, not hard coded values. So:

Code: Select all

in$ = in$(temp to temp2-1)

And temp2 just happened to be the same as temp, so it returned an empty string.

Cheers,
Norm.

[martyn_hill]

Hi everyone!

I concur with Per - the case of "n TO n-1" (or, similarly "n+1 TO n") results in a valid, empty string and is "philosophically" not an error.

Its actually quite useful (for lazy programmers like me), as you can catch the result and know that you have now scanned-passed the end of the source string by checking for empty string result - without triggering an error.

If I recall correctly, this did come up some years ago here on the forum when discussing SMSQe's string handling - might be worth searching the forum again to understand the "philosophy."

Happy New Year!

[NormanDunbar]

While I'm happy to agree about returning an empty string in this case, it should be consistent so that any attempt to slice from a larger index to a smaller one should either return the empty string or return an error, but not this pile of pants!

This is, currently, as I found in SSB, a bug.


Cheers,
Norman.

[pjw]

Apropos nothing, I just thought y'all might enjoy this little number by xkcd: