Sorry for the basic question, but why does it not return a pointer to an unsigned char? I mean, I looked in K&R but it does explain the rational (as far as I could tell...)
Thanks
The only time I can see that it would be a trouble is when comparing two strings. But then again, requiring the C standard to support configurable collation orders would very much affect the speed and size.
Signed/unsigned does not mean that the string functions are limited to 7-bit ASCII. It is just a question of how the upper 128 characters should be viewed.
Many compilers has a compilation flag to specify if the default should be signed or unsigned, but I normally never use this flag. It is better to write the code to don't care about the sign of char. After all, we got the two keywords signed and unsigned to allow us to specifically force the required representation when it is important.
"After all, we got the two keywords signed and unsigned to allow us to specifically force the required representation when it is important."
Absolutely ...
I simply have two typedefs in a common header file for SByte and UByte respectively.
Becomes second nature to use them after a little while.
The trouble comes with compilers that try to be (too) helpful by warning whenever you have a signed/unsigned mismatch (especially via pointers).
So, if you've carefully defined all your text as 'unsigned', you can get loads of warnings with the string library functions...
:-(
Therefore I have three typedefs in my header:
U8 - for 8-bit things that specifically need to be unsigned;
S8 - for 8-bit things that specifically need to be signed;
TXT - for things that are "text" and, therefore, likely to be used with the string library functions.
Thanks - That's an interesting one.
So don't do that, then! :-)
I don't (any more) !
The point is that having just U8 and S8 (or equivalent) is not sufficient - you do also need some kind of "unadorned" char...