My friend was messing around with Str8 when it started acting extremely broken. As you can see from the screenshots, the length( command returns not only wrong values, but different values each time. If you recall Str8, the last character appears to be expr(, but when using the sub( command to check the last character it gives you npv( or RandBin(. If you use inString( for any of those tokens, then it always returns 0.




If we try to send it to other calculators, then half the time it leads to ERR: Version. If you do Str8 → Str9, then Str9 is also broken. However, if you do sub(Str8, 1, 8187) → Str9 (which should store the entire Str8 to Str9) Str9 is no longer broken. If you send it an older calculator (older than a CE) and test the length, then the calculator cannot find the length. It gets stuck trying to find the length forever (you'd have to reset the calculator). If you send the string to SC3 and export it, then it is no longer broken.

EDIT: The string was made by a program that stored only random uppercase and lowercase letters to a string. Also, if you delete the last character in the string (whatever it may be), then everything works fine.

If you want to download and test the string yourself, download it here: https://drive.google.com/file/d/1Vl-dWnH8mPejgDRt2qtqLgOD3wFRkXN_/view?usp=sharing

Why was your friend using strings that were that long in the first place??? Was it for some kind of program? Is it encrypted? Or did he just feel like making ridiculously long strings?

It sounds like it might be a partial token at the end of the string - do you have a CEmu RAM dump we could use to investigate?

Commandblockguy is right about the partial token: The string ends with half an extended token (starting with 0xBB). This can be confirmed by looking at the raw data, but I figured it out from the list of tokens that could appear at position 8187. They are all present in http://tibasicdev.wikidot.com/miscellaneous-tokens, which lists the two-tokens starting with 0xBB.

• Every time it reads the string, whatever comes next in memory is interpreted as the next byte of that token.
• When attempting to send it, it will fail with a version error if it happens to think the token is one that cannot be sent to the target model.
• When attempting to determine the size, it keeps reading until it reaches what it thinks should be the end of the string...but it evidently keeps going if it happens to overrun the actual end, resulting in varying values larger than the correct length. (EDIT: Or smaller if it overflows.)