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
I thought it simply returned char, with the sign of char being implementation specific.
Hi, I'm using µVision and the Armcc compiler and there is an option in the project settings saying "Plain Char is Signed". If this flag is set, it returns a signed char.
Maybe you also got such kind of flag.
Yes, that's the trouble with all the standard 'C' string library functions!
:-(
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.
"TXT - for things that are "text" and, therefore, likely to be used with the string library functions."
How droll of me. I'm jusing "char" :)
You wait and see how far that gets you if you ever have to program under MISRA C rules, one of which is "no use of fundamental types like char, int, etc. except in typedefs".
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...