Re: signed vs unsigned pointer warning

[kaih at khms dot westfalen dot de (Kai Henningsen)]

terra@gnome.org (Morten Welinder)  wrote on 08.10.04 in <20041008173153.E89761422D56@darter.rentec.com>:

> And regardless of the implementation's value of EOF, you cannot cast to
> "unsigned char" either because that would make EOF collide with one of
> the other 256 valid inputs.

The usual problem is that either you already have (implicitely) cast to  
char where you shouldn't gave (the classic while((c=getchar())!=EOF) bug),  
or else you just have EOF-less data anyway but it's in char*.

In the first case, obviously the answer is to make c an int as it should  
have been in the first place, so you can distinguish between EOF and  
(unsigned char)255 - there's a reason getchar() returns all characters as  
unsigned char values. Then no casting is needed for isXXX().

In the second case, there's nothing wrong with casting to unsigned char -  
in fact, that is exactly what is necessary. You can, of course, do it by  
accessing your data with an unsigned char * pointer instead. That's just a  
question of what looks better to you.

And I should mention wint_t/wchar_t here just for completeness.


Really, the fundamental bug was when the first C standard failed to have  
separate unit-of-storage and character types, and allowed the fundamental  
character type to be signed (and forced it to always be one storage unit,  
thus wchar_t). There's really no good reason for characters to have signs.  
(There occasionally is, of course, for storage units.)

It's probably far too late to fix that, unfortunately.


Anyway, the facts of life are that we have character-handling interfaces  
that insist on unsigned chars (getchar(), isXXX()), and we have others  
that insist on unadorned chars (strXXX(), "..."). And thus, we need extra  
intelligence to figure out where we should or should not warn about  
signedness-of-char issues.

Let this be a lesson to language designers about how NOT to do it.

MfG Kai