signed/unsigned char/short/int/long

[Doug Gwyn]

In article <277 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>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.

But that is NOT what the dpANS says.  unsigned int and signed int are also
distinct types.  They are guaranteed to have the same representation and
alignment requirements (for the values that they share) when used as
function arguments or union members, but that does not reflect on their
types.

>I would not agree that char has never been a length specifier for int;

Certainly not in the sense that you mean for "short".  "short int" is
valid, but "char int" is not and never has been.  char is a basic integral
type (of uncertain signedness).

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

I don't know what "fuss" you refer to.  Your complaint about "signed"
is the first complaint I have heard.  "signed" is in fact existing
practice in several compilers, although not in K&R 1st Edition.  It
really isn't necessary for anything except "signed char".  The reason
it is necessary there is that "char" has explicitly been defined as
being possibly signed, possibly not, depending on whatever was most
efficient for the specific implementation.  "signed char" provides a
way to force the signed flavor in cases where it matters.

The rules for promotion of types in mixed expressions really have
nothing to do with "signed", since "signed int" means EXACTLY the same
as "int" (for example).  The complicated wording you gave for conversion
rules seems to amount to much the same as in the dpANS, only less precise
and less complete.  You should study the examples in the Rationale
document to see what subtleties are involved.

>[under Grandi's proposal]...
>char by itself may be either, char int and char unsigned are well defined.

But that really is contrary to existing practice, as you unjustly
accused "signed" of being.  Try "char int" on a typical PCC and you
will get an "illegal type combination" error message.

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

The party line on trigraphs is that they are primarily meant to aid
C source code interchange between systems with widely varying character
sets, not as something to be used in normal programming practice -- where
other approaches that are more suitable are envisioned (and allowed by
the proposed standard as the first part of translation phase 1).  I'm
frankly not at all certain that the latter point was really widely
appreciated by the committee until fairly recently, but it is now.

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

I don't think that was intended as "damning with faint praise".  Dennis
has in the past expressed his appreciation of the committee's work.  The
one thing he was unhappy about was the way we had type qualifiers set up
in the second formal public review draft of the standard.  This has been
fixed, with help from Dennis and a few other public reviewers.