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

[Piercarlo Grandi]

I am happy I managed to sidetrack the sterile discussion on macros in
cpp into something dearer to my heart (can you say "axe to grind" ? I
can ;->...).

I am relieved that the dpANS does not imply prescience and telepathy
are required in cpp or the compilers to understand which macros are
parameterless and which are not :-) :-)...

On the other hand the substance of my point on unsigned/int remains; I
apologize to Doug Gwin for having used the wrong terminology.

What I really was unhappy with in dpANS (among many other things...) is
that signed has been introduced as a new keyword, and I ought to have
said unsigned/signed, not unsigned/int.

As I understand it, this means that char,short,int,long are distinct
types, whereas unsigned and signed are type modifiers. In a sense then,
the view of dpANS is that unsigned [int] and [signed] int are the same
type, only that one has a sign and the other hasn't.

Clearly this mostly is a matter of emphasis, in that unsigned short and
signed short are distinct types, as would be short unsigned and short int,
but it is quite important to note that in dpANS there is an explicit
affinity between unsigned and signed short, not between short and long
unsigned, even if we concede that type modifiers create new types, instead
of merely subtypes.

I would not agree that char has never been a length specifier for int;
before dpANS, C was defined by Ritchie's and Johnson's compilers (in a
sense even K&R was just the manual for the compilers). In both
compilers, and reading carefully K&R, one has the strong impression
that, beyond a somewhat artificial distinction between integral and
integer types, char was always meant to be a kind of short short int,
and indeed one can apply to a char all the same operations one can
apply to an integer; also the rules about lengtheneing of char and short
in many contexts, and the common use of int where char could have been used,
tend to reinforce the impression.

I would also not agree that in this matter dpANS respected existing
practice; the introduction of the signed modifier is certainly an
innovation, and a confusing one as well (judging from all the fuss
about it and char).

In Johnson's compiler instead one can fully use char,short,long as type
modifiers, and int and unsigned as based types, and I regard this (in
my never humble opinion) as the most natural thing to do, and one that
would not have required the introduction of signed.

    I understand that using a compiler as definition of a language is
    not kosher, but before dpANS this was the way (fortunately :->).

Using this interpretation, there is little argument about adopting a
"[un]signed preserving" or "value preserving" rule; the only rules are
that conversion from a shorter to a long form of the same type results
in no changes, and tyhe same applies when a longer value is shortened
to a length that can represent it, and conversion across the two base
types is defined only if the source unsigned is not too large or the
source int is not too large or negative; anything else is machine
dependent, except that truncations to a length of unsigned must respect
the rules of modular arithmetic.

This interpretation may not be what Ritchie, Johnson and K&R meant, but
it is consistent with them (well, I admit that saying char int and char
unsigned is somewhat funny, but you can get used to it ;-}), especially
with the point that unsigned obeys a different type of laws of
arithmetic (modular) than int (algebraic), thus distinguishing them
more forcefully than differences of range, that after all are just
accidents of implementation. Note also that there is no need of a signed
keyword to disambiguate between variations of char in this interpretation;
char by itself may be either, char int and char unsigned are well defined.

As to the rest of dpANS, I will not rekindle spent discussions, except
for a cheap leer at trigraphs :-) :-) (I understand that the committee
were more or less forced to include them, so it is not wholly their
fault...).

As Ritchie said (more or less) in an interview to Computer Language:
"dpANS C is the best standard that could have come out of a
committee".
-- 
Piercarlo "Peter" Grandi			INET: pcg at cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)