signed/unsigned char/short/int/long [was: #defines with parameters]

[Richard A. O'Keefe]

In article <375 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>My contentions (for the last time!) are that
>
>    [1] this is not necessary, as it is more natural to drop the pretense
>    that "char" is a type distinct from "int", and instead adopt the notion
>    that "char" is like "short", an adjective that modifies the length of its
>    base type;
>

That change would *FORCE* compiler writers to break working code.
There are programs which were written for machines with unsigned chars
(predating the introduction of 'unsigned char') where the programmers
relied on the char range being 0..255.  While this was not _portable_,
that implementation was _permitted_.  If you now rule that
	char = char int and is *signed*
then to conform to the standard, compiler writers for those machines
would _have_ to make plain chars signed.  The method X3J11 chose
_allows_ compiler writers for those machines to keep their old semantics
for plain 'char', and thus lets them offer backwards compatibility to their
customers.  It simply wasn't possible to make the new standard compatible
with all the old compilers, but X3J11 didn't introduce incompatibility
lightly.

Don't forget, the signed/unsigned ambiguity of 'char' was provided in the
first place for very practical reasons:  there are machines where signed
chars are more efficient, and there are machines where unsigned chars are
more efficient.  That is still true, so we _still_ want a way of saying
"whichever of signed byte/unsigned byte is cheaper, I promise not to care".

To be perfectly frank, I don't expect to have any use for 'signed char'.
I particularly don't want all my programs which use 'char' (because I
wanted the efficiency and didn't need a large range) to be forced to use
signed bytes, so the "char = char int = signed char" rule, while it
would not _break_ my programs, would definitely make them less efficient.
NO THANK YOU!