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

[Richard A. O'Keefe]

In article <420 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <860 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>	[ on my suggestion to make "char int" denote guaranteed signed chars ]
>    That change would *FORCE* compiler writers to break working code.

>Why ever? I have never advocated removing the rule that "char" by itself is
>either "int" or "unsigned", merely added a way to guarantee that it would be
>signed.

So sorry!  I thought you wanted your proposal to be self-consistent.
Silly me.  The proposal, as I understood it, was that 'char' was to be a
size modifier _just_ _like_ 'short' and 'long'.  Now the rule is that
	short x;	==	short int x;
	long x;		==	long int x;
so naturally I assumed that you were proposing that
	char x;		==	char int x;
(Certainly "short short" would have worked like that.)

>    but X3J11 didn't introduce incompatibility lightly.
>
>Yet it introduced an unnecessary keyword.

It has been explained that X3J11 did not "introduce" the 'signed' keyword,
but accepted it as _existing_ _practice_.  If someone else has tried to
deal with a problem, you don't spit in their face even if you don't like
their solution much.  

>Indeed!. Since 'char' is  to be a length modifier, I assumed it was obvious
>that in case the base type is missing, it would default to either 'int' or
>'unsigned', while for all other length modifiers it would always default to
>'int'.

I'm sorry, but I don't see how such an exception is "obvious".

I personally regard the whole of C's integer type system as radically
misguided, and would argue with the utmost vehemence against its adoption
in any other language.  But C is the way it is, and there is no use
crying over spilt milk.  It's usable, it's understood.  Let's freeze it
and get on to better things.