pcg@aber-cs.UUCP (Piercarlo Grandi) (12/06/88)
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. In article <225@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: In article <277@aber-cs.UUCP> pcg@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. If you want to, you can think of this as types and modifiers, though the standard does not speak of them that way. If so, here is how you do it: The types: char int That's right. Only two. The modifiers: unsigned signed short long The first pair modifies char or int; the second int only. You can specify only one of each pair. OK, the standard does not speak of modifiers and types, but then the result is the long lists you give and lots of confusion. I think there are two issues here, one the introduction of signed as a keyword, and the other neat ways of defining semantics. As to the latter, the whole type system would be greatly simplified if one were to say that [1] there are two distinct types, int and unsigned; they are distinct types because different rules of arithmetic apply to them. This would make it clear, and I have found very few people that actually understand that unsigned is not just "positive int", that the same operators applied to int and unsigned have very different semantics. [2] Each of the two distinct types may come in three different extra lengths, char, short and long, that are exactly equivalent among them for the same type except for the different size. 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. Historically char constants have been really the size of integer constants... I would have liked, instead of the unnecessary and confusing signed modifier, a nice range(abs_max) modifier for types integer and unsigned, and char/short/long defined in terms of it. This would have added tremendously to the portability of programs. The lack of some sort of ranges and the use of short and long are one of the few things I dislike in Algol68 and C. I hope such an interesting extension makes it into C++, or at least into the GNU C++ compilers (hint hint Michael Tiemann!). There is no relationship between char and signed or unsigned char, other than that they occupy the same amount of storage. 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"? Since storage classes, modifiers, and type names could be given in any order in a declaration; most compilers therefore simply collected keywords, and set a flag in the symbol table entry for the variable for each keyword they collected. This meant that "int static char int static" was accepted as a legal declaration by many compilers :-). This has been later often "corrected", notably in 4BSD pcc. 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... Of course in my opinion both ought to be 1, or an order storageclass/modifier/type might be enforced, making "int char" illegal and "sizeof (char int)" equal to 1. -- 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)