emjej@uokvax.UUCP (05/30/84)
#N:uokvax:3000026:000:822 uokvax!emjej May 30 10:33:00 1984 Apologies if this has been gone over before, but I tripped over this yesterday: strict exegesis (or pilpul, depending on your religion) of K & R indicates that the strings unsigned short unsigned char unsigned long do not denote legitimate types in C, yet I see these in various places (some Berkeley header files, for example). Have these types been blessed somewhere (like the enum types) without mention? (For that matter, does the C++ (that name bothers me, BTW: they changed the language but you get back the value before the change? :->) CTR leave this section of the C Reference Manual unchanged? Side note: I sincerely hope that the fellow from Mark of the Unicorn who wrote an extraordinarily wrong letter to SNot about how we don't need a standard for C is reading this newsgroup... James Jones
guy@rlgvax.UUCP (Guy Harris) (06/05/84)
> strict exegesis (or pilpul, depending on your religion) of K & R indicates > that the strings > unsigned short > unsigned char > unsigned long > do not denote legitimate types in C, yet I see these in various places (some > Berkeley header files, for example). Have these types been blessed somewhere > (like the enum types) without mention? "unsigned long l;" parses as declaration | +------------+-----+----------+ | | | decl-specifiers declarator-list ';' | | +--------------+ +---------+ | | | type-specifier decl-specifiers init-declarator | | | 'unsigned' type-specifier declarator | | 'long' identifier | 'l' and is equivalent to "unsigned long int l;"; the key passage is in the C Reference Manual, "8.2 Type specifiers": If the type-specifier is missing from a declaration, it is taken to be "int". This passage can either be interpreted as "if you leave all the type- specifiers out, it's as if you put in 'int'" or "if you have nothing but 'adjectives', it's as if you put in 'int'" (see the paragraph containing the above passage, which describes "long", "short", and "unsigned" as "adjectives"). So the exegesis is dependent on the interpretation of that passage; the Ritchie and Johnson compilers both use the second interpretation. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
keesan@bbncca.ARPA (Morris Keesan) (06/12/84)
------------------------------ > > strict exegesis (or pilpul, depending on your religion) of K & R indicates > > that the strings > > > unsigned short > > unsigned char > > unsigned long > > > do not denote legitimate types in C, yet I see these in various places (some > > Berkeley header files, for example). Have these types been blessed somewhere > > (like the enum types) without mention? > > "unsigned long l;" parses as > . > . [parse diagram omitted] > . > and is equivalent to "unsigned long int l;"; the key passage is in > the C Reference Manual, "8.2 Type specifiers": > > If the type-specifier is missing from a declaration, it is > taken to be "int". > > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy Actually, the key passage is in the same section Guy cites, just prior to his citation: The words long, short, and unsigned may be thought of as adjectives; the following combinations are acceptable. short int long int unsigned int long float The above is from K&R, and therefore the original poster was right: by omission, strict exegesis of K&R forbids any other combinations. The passage as above also appears in the C Reference Manual in the UNIX V7 documentation. The System V documentation (and perhaps earlier USG/UGLIX versions of C) add unsigned char to the list of acceptable combinations (page 89 of System V "Programming Guide"), so it has been "blessed somewhere", but not without mention (similarly enum types are mentioned, if you know where to look for them). The remaining two forms, unsigned short and unsigned long, are not blessed by any Bell Labs documents that I know of. I know that by adding the two types "unsigned char" and "void" to our V7 C compiler (along with some changes, but without the addition of the two disputed "unsigned" types), we were able to successfully compile all of the System V source. Apparently the long and short of it are Berkeleyisms. Can anyone confirm this? Is there a manual for Berkeley C? -- Morris M. Keesan {decvax,linus,wjh12,ima}!bbncca!keesan keesan @ BBN-UNIX.ARPA
adm@cbneb.UUCP (06/13/84)
#R:uokvax:3000026:cbnap:16200004:000:178 cbnap!whp Jun 13 15:54:00 1984 I remember hearing somewhere that an unsigned long has a smaller maximum value than a regular long, for some systems. I think the VAXes were mentioned. Can anyone confirm this?
guy@rlgvax.UUCP (Guy Harris) (06/22/84)
"unsigned short x;" and "unsigned long x;" aren't Berkeleyisms. The 4.1BSD
C compiler differs from the System III C compiler ("compiler" here refers
to "/lib/ccom") in 1) the addition of "flexnames", 2) a mod not to put anything
shorter than 32 bits declared "register" into a register, and 3) other
very minor changes - these differences were found by using the "diff" command.
The System V source file "getty.c" contains the line
unsigned short timer;
so the System V compiler supports it (any other result would have surprised
the living **** out of me). Therefore:
1) the PDP-11 V7 Ritchie compiler already supported them, and your
compiler (being based on that compiler) didn't need to be changed
to support them.
2) your System V source to "getty.c" (and some other programs,
probably) was a PDP-11 distribution; the PDP-11 S5 compiler
doesn't support "unsigned short x;"; and all file using this
construct were modified not to use it.
3) somebody at BB&N changed "getty.c".
I infer from what you say that 3) isn't the case. 2) is unlikely, but not
impossible; I put my money on 1).
I interpret "8.2 Type specifiers" to say that there are two classes of
"type-specifier", adjectives and nouns. "long", "short", and "unsigned"
are adjectives, and the others are nouns. ("The words 'long', 'short', and
'unsigned' may be thought of as adjectives...") A declaration consists of one
noun ("Otherwise, at most one type-specifier may be given in a declaration.")
and several adjectives. The adjectives "short", "long", and "unsigned"
may modify "int", and the adjective "long" may modify "float". No other
combinations of adjective and noun are permitted. ("...the following
combinations are acceptable.")
In the statement "If the type-specifier is missing from a declaration, it
is taken to be 'int'.", I interpret "the type-specifier" to refer back to
the "one type-specifier given in a declaration" mentioned in the previous
sentence. As such, in "unsigned short int" the "int" is the missing
type-specifier, so "unsigned short" is a declaration with the type-specifier
(in the sense used in that sentence) missing and taken as "int".
I see no reason this shouldn't be considered a legitimate interpretation; I
don't find it far-fetched, forbidding "unsigned" to be applied to "short int"
and "long int" reduces the usefulness of the language, *and* it describes
current practice for a lot of existing compilers and code. I consider the
other interpretations legitimate as well, which is why I consider the passage
ambiguous.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy