signed/unsigned char/short/int/long

[Richard A. O'Keefe]

In article <347 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>This is not
>suprising, considering that C is a descendant of BCPL (whose single most
>annoying feature is having to use putbyte() and getbyte() for string
>manipulation, as it has just one length of integer).

That hasn't been true of BCPL for a long time.  BCPL has two subscripting
operators:
	base!index		index is a word offset, form addresses a word
	base%index		index is a byte offset, form addresses a byte

>In a sense C is a wonderfully equilibrated mix, BCPL with quite a good lot of
>Algol68 thrown in, and this shows thru in things like some semantics
>(BCPL-ish) of integer types, and their syntax (Algol68-ish).

The semantics of C integral types resembles Algol 68 (which has e.g.
int, short int, short short int, long int, long long int) rather than
BCPL, which has only one type "word".  The syntax of C constants
resembles BCPL rather than Algol 68 (e.g. no general "radix" notation,
characters as integer constants rather than char constants, \escapes
-- BCPL uses *escapes, Algol 68 has no escapes at all).

>    introducing the signed keyword and related paraphernalia instead of
>    allowing "int char" (an existing unintentional "feature" of some
>    compilers, by the way) to do the trick,

I will make an argument against this.  "int" does *not* in general have
the meaning "make it signed".  For example, "int unsigned", if accepted,
is not signed!  I would definitely expect that if "int char" or "char int"
were accepted at all, they would be identical to "char" in every respect.
What *would* have been consistent with C's intellectual ancestry, and
*would* suggest signedness, would have been introducing
"short short int" = "signed char" and
"unsigned short short int" = "unsigned char".  But I'm quite sure that
X3J11 considered this and rejected it for good reasons.