draft ANSI standard: are chars signed?

[roz at l.cc.purdue.edu.UUCP]

In article <1462 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>In article <783 at nscpdc.NSC.COM>, joemu at nscpdc.NSC.COM (Joe Mueller) writes:
>> The committee wanted to "fix" the question of signedness of a char
>> [....]
>> We ended up
>> adopting the compromise of:
>> 	char	- signed or unsigned, implementation defined
>> 	unsigned char
>> 	signed char
>
>Of course, this compromise breaks all the code that depends on chars
>being EITHER signed OR unsigned!  To be portable and "strictly
>conforming", you can't depend on =chars having signs= or =chars having no
>signs=, you just can't depend.

Now I'm not claiming to be a C expert, but isn't it what's going on now, that
you "just can't depend" ?  Isn't it the current state of affairs that char's
are either signed or unsigned, implementation defined ?  If your codes *are*
depending on one or the other, then they are not at all portable.

>I would rather they had broken half the code that makes assumptions,
>rather than all of it.

Of course, unless I'm wrong, they're not breaking ANY code, since all they did
was adding two more types -- signed char and unsigned char -- , not changing
any current type.  So apparently *no* code is broken.
-- 
Hao-Nhien Q. Vu (pur-ee!l.cc.purdue.edu!vu)
                (vu at l.cc.purdue.edu)
[That's "ell", not "one"]