Fun with negative zero and arrays

N0=&H80000000
S$="HI"

FOR I=0 TO 100000
UNSHIFT S$,S$[N0]
? S$[N0];
NEXT

This code appears to be accessing uninitialized memory of some sort. You can also try reading/assigning more than one character to S$[N0] and the application will either crash and reboot, or just hang, depending on the string and how many charactors assigned. The interesting thing is that this is fixed in the latest JPN version (3.6.0) but still unfixed in US/EU 3.5.2. I haven't disclosed this to anybody until now.

Oh, another one of these? Well we don't have long with this one apparently. Just so we're clear, N0 in your example isn't negative 0, it's -2³¹.

Oh, I guess other people have secrets too. Well, hopefully they fixed some other string bugs along with this one.

It actually seems like there's a special value stored at this index in each string, but it's not clear what it is. It doesn't appear to be poking at inaccessible memory, since if you walk backwards from that index, you actually get the string!

VAR S$="HELLO WORLD"
FOR I%=&H80000001 TO 0
 ?S$[I%];
NEXT

So in each string, &H80000000 is our mystery char, and working backward is the string itself. Any index beyond then is out of range and throws an error.

Well it makes sense... This is the dev simulating a signed integer by modding it to the max integer size, however, 2147483647+1 should be equal to -2147483648, not 0. So that's either a bug or the developer knowing something about the app's structure that we don't. I really wish SmileBASIC was open source.

Well it makes sense... This is the dev simulating a signed integer by modding it to the max integer size, however, 2147483647+1 should be equal to -2147483648, not 0. So that's either a bug or the developer knowing something about the app's structure that we don't. I really wish SmileBASIC was open source.

What do you mean? 2147483647+1 is 2147483648 (automatically converted to a float since the result is to large to fit in an integer)