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

[Doug Gwyn]

In article <330 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>First of all I wish to admit I have been inaccurate; as somebody remarked
>"noalias" was only briefly in the dpANS C, and "far" and "near" never
>actually made it in the official documents sent out for review. But all
>were for a long time in various drafts, and as usually happens people
>actually advertised "far" and "near" as examples of draft, unofficial
>ANSI C conformance. Thank goodness X3J11 frustrated their efforts in the end.

You're still inaccurate.  "far" and "near" were never at any time in
any draft of the proposed ANSI C standard.

"noalias" was not in any draft other than the one sent out for the
second public review.  How could it be, when it had just been invented
at the previous meeting and was retracted at the next?

Are you just making this stuff up, or do you have drug-using advisors,
or what?

>As to the last point, char has been so far just a short short; a char
>value can be operated upon exactly as an integer.

Except that whether it acts as signed or unsigned depends on the
implementation.

>Historically char constants have been really the size of integer
>constants...

You mean "character constants"; in C they ARE integer constants
specified in a certain character-oriented way.

>Now I reiterate the question: why was a new keyword introduced "signed"
>when it just sufficed to sanction the existing practice of some
>compilers (PCC had it, more recent BSD versions fixed this "bug") to
>say "int char" or better "char int"?

I have never seen a C compiler that accepted "int char"; certainly
Ritchie didn't intend for it to be valid.  Also, char has never been
guaranteed to be signed; read K&R 1st Edition.  It happened to be most
efficient on the PDP-11 to make it signed, but it was implemented as
unsigned on some other architectures.  The VAX port of the C compiler
could have done it either way; signed behavior was chosen, presumably
to aid in porting code developed on the PDP-11.  The IBM 370 and WE 3B
compilers had chars act as unsigned all along.  Ritchie specifically
blessed this implementation dependence in his BSTJ article on C in 1978.

>Amusingly it persists even today in other compilers, among them
>g++ 1.27, where interestingly "sizeof (char int)" is 4 and "sizeof
>(int char)" is 1 on a 68020...

I don't know what C++ rules for basic types really are, but if as I
suspect g++ is getting it wrong, you should report this bug to the GNU
project.