SCI1.1 File::readString first byte

[doomlazer]

Consider a text file containing the alphabet. If we use the File class's readString with a max size property of 5 and then print the string, the output is 'abcd', if the max size is 1, then we get a blank text box; max size of 2 results in 'a'.

A hex editor confirms that the first byte of the text file is 0x61 (a), so what's up with that 'empty' first byte in the max size property?

[Kawa]

When I started writing this reply, I figured it could have to do with the simple fact that SCI, at least until the 32-bit versions and even then barely, had no concept of an 8-bit value and thus has to read a multiple of two bytes at a time.

But then I looked at your numbers and results again and now I'm thinking it's a null-terminator issue. You asked for five characters, so you got four + the null terminator. You asked for one character, so you got only the terminator, etc.

After all, you gotta know where to stop reading.

[doomlazer]

I guess it is the trailing 0x00 string terminator. Kinda annoying though. It should know to stop reading via the max size. Why do I need to +1? Also, if you set max size larger than the file it knows to stop anyway. *shakes fist at clouds*

[doomlazer]

Avo323 (can someone please approve his registration?) is telling me File::read doesn't have this extra byte. I guess this lends credence to 0x00 string thing

[Kawa]

Avo323 is already approved.

[doomlazer]

lol, nobody tells me anything around here! The site probably isn't sending out notification emails anymore though. At least not in my experience lately.

[troflip]

The size represents the size of the buffer you're writing these characters into, not the amount of characters to read. This helps mitigate buffer overflow errors.

Given that strings must be null-terminated, there needs to be room for the trailing 0x00.

[doomlazer]

Ah, ok. I'll always set the max size to the size of the buffer then. TY