This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: signed vs unsigned pointer warning


On Fri,  8 Oct 2004 13:31:53 -0400 (EDT) terra@gnome.org (Morten Welinder)
wrote:

> 
>    Why can't an implementation define isxxx(c) to return something like
>        table_lookup[(unsigned)(c)]
>    ?
> 
> Because isxxx needs to work with EOF, typically -1.

So what? On my system all the is* calls return the same thing for EOF as
they do for 255, namely 0. Is there an actual locale where any of the
is*() calls returns non-zero for 255? In any case, for the usual western
locales, your argument is invalid.

> 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.
> 
> So to summarize: someone screwed up with the definition of isxxx and it
> is not fixable by the implementation.  Therefore, get used to seeing
> code like
> 
>      const char *foo = whatever;
>      if (isspace ((unsigned char)*foo)) oink ();
> 
> no matter how ugly it is.

I've grepped through a couple sources I had lying around. I don't think
we'll have to get used to this anytime soon. Almost everyone just seems to
pass signed chars to the is* functions. It's the DE FACTO standard and
libraries/compilers better implement it. And as stated above, for the
usual western locales, you can implement it without violating the
standard, so not supporting signed char arguments would be completely
irrational.

MSB

-- 
You know that you're lonely when you start laughing at your own jokes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]