Nice call, John.
Too bad the OS code wasn't fixed to use "byte" instead of "char" when
the "const"s were finally put in.
Hey, in 20 years, I've used "signed char" twice. 8-bit audio samples
were one instance. Don't remember the other. Anybody else used "signed
char" more often? :)
The use of "char" is, in my opinion, is a bug for two reasons:
1) Modern compilers can compile "char" to be either signed or unsigned.
Any reusable code you write shouldn't care which type the compiler is
set to.
2) Unless you're in pure ASCII, you really meant "unsigned char".
Non-English language people must be driven crazy by "signed char *"
strings.
But then, when you always use BYTE, as I do, compilers that can't have
their "mismatched pointer type" error messages turned off can lead to
lots of ugly, dangerous casts, so, YMMV. Anyway, compilers requiring
gratuitous casts are another soapbox. ;)
John Marshall wrote:
>
> While testing my ErrorCodes application, I've found that SysStringByIndex
> appears to have difficulty handling tSTL resources containing between
> 128 and 255 strings. (And probably similarly between 384 and 511, etc.)
>
> For example, consider a resource containing 150 strings.
>
> For 0 .. 149, everything is fine.
> For 150 and beyond, when it should be returning more or less empty
> strings, it starts returning (the prefix concatenated with) random
> garbage.
> If you ask for something ridiculous like the 65000th string, instead
> of quickly realising that that's well beyond the number of strings
> in the resource, it sits there scanning through the garbage looking
> for the 64999th '\0'.
>
> I haven't done the source code license thing, but with my eyes shut my
> diagnosis is:
>
> I think the code in SysStringByIndex which computes the length
> field from the two bytes right after the prefix string is doing
> it in *signed* chars, and so the 128 bit of the low byte is
> being sign extended.
>
> John "also I predict that the letters RM will be found nearby :-)"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
