Xref: utzoo comp.lang.c:14876 comp.lang.c++:2267
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!gatech!hubcap!ncrcae!ncrlnk!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: signed/unsigned char/short/int/long [was: #defines with parameters]
Message-ID: <420@aber-cs.UUCP>
Date: 17 Dec 88 17:15:59 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: CS Dept., University College of Wales, Aberystwyth, UK
	(Disclaimer: my statements are purely personal)
Lines: 47

In article <860@quintus.UUCP> ok@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.

    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*

Never implied this. (I care about backwards compatibility, even if I don't
like it where is rewards, like in your example, non portable practices).

    but X3J11 didn't introduce incompatibility lightly.

Yet it introduced an unnecessary keyword, the perpetuates the unfortunate
syntax that favors the confusions that "char" is indeed a type and "unsigned"
is indeed just a variant of "int".

    [ .... ] we _still_ want a way of saying "whichever of signed
    byte/unsigned byte is cheaper, I promise not to care".

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'.

In dpANS C the rule is conversely that the type modifier 'signed' is the
default for all the lengths of 'int', but not for type 'char' where the
default may be either 'signed' or unsigned'.

    To be perfectly frank, I don't expect to have any use for 'signed char'.

I have, I have! (I mean "char int" of course). In many many cases one wants
to really consider "char" a length specifier, and create arrays of byte sized
integers or unsigneds (or don't cares).
-- 
Piercarlo "Peter" Grandi			INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)