draft ANSI standard: are chars signed?

[news at cit-vax.UUCP]

Organization : California Institute of Technology
Keywords: 
From: jon at oddhack.Caltech.Edu (Jon Leech)
Path: oddhack!jon

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 but
>> couldn't arrive at an acceptable compromise. We thought about having
>> chars be signed and unsigned chars unsigned but we were afraid it would
>> break too much code that depended on chars being unsigned. 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.
>
>I would rather they had broken half the code that makes assumptions,
>rather than all of it.

	I fail to see how this choice 'breaks' ANY code. It is
not possible to write portable code with either of the above assumptions
now. It will not be possible under ANSI - but it will then be possible
to explicitly choose signed chars if you want. What broke? If you
are saying ANSI should have chosen chars to always be signed or unsigned
just so currently broken code will become non-broken, I don't agree
with the complaint. Who knows how much inefficiency may result? 

    -- Jon Leech (jon at csvax.caltech.edu || ...seismo!cit-vax!jon)
    Caltech Computer Science Graphics Group
    __@/