Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness

[Ganesan R <rganesan@myrealbox.com>]

>>>>> "Steve" == Steve Greenland <steveg@moregruel.net> writes:

> On 31-Dec-01, 19:42 (CST), Ganesan R <rganesan@myrealbox.com> wrote: 
>> Another thing that puzzles me since this whole debate started. If you look
>> at the declaration of ctype.h functions (isalpha family), they take a int as
>> an argument.

> I don't know that I agree about needing to pass them unsigned char,
> though. The char->int conversion should be value preserving. If you pass
> a negative value, then you are making a domain error, and deserve what
> you get.

Are you saying that isalpha() etc should work for negative values or that
you should never call isalpha() with negative values for chars? In a
ISO8859-1 locale when I call isalpha() for accented characters I should get
expected results without worrying about whether the accented character is a
signed quantity. Unfortunately older C library implementations may break
because an accented character will take a negative index on a character
table without proper casting. 

I followed up a bit on this and found out that ISO C specifically states
that ctype functions should work for all values of unsigned char as well as
the default char type. In other words, if the default C char type is signed
you can just call the functions without any cast and expect it to work.

Ganesan