Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site bbncca.ARPA Path: utzoo!linus!bbncca!keesan From: keesan@bbncca.ARPA (Morris Keesan) Newsgroups: net.unix-wizards,net.lang.c Subject: Re: unsigned char -> unsigned int conversion Message-ID: <790@bbncca.ARPA> Date: Wed, 20-Jun-84 11:37:12 EDT Article-I.D.: bbncca.790 Posted: Wed Jun 20 11:37:12 1984 Date-Received: Thu, 21-Jun-84 01:25:27 EDT References: <3961@utzoo.UUCP> Organization: Bolt, Beranek and Newman, Cambridge, Ma. Lines: 27 ----------------------------- > The C Reference Manual that's part of the K&R book is a little vague > on the subject of what types "unsigned" can be applied to. In the > detailed discussion it says that "unsigned int" is the only legitimate > form, but elsewhere it implies the existence of "unsigned long" in > some implementations. > > Note that even the V7 compiler accepts "unsigned short". > . . . > Henry Spencer @ U of Toronto Zoology I'm well familiar with the "detailed discussion" (section 8.2), since I've been citing it a lot recently, but where "elsewhere" does it "imply" unsigned long? I checked BBN's C compiler for our C/70 machine, which is based on the V7 PDP-11 C compiler, and found that it does indeed accept "unsigned short". Curious, I checked to see why and discovered that it's because "short" is defined as lexically equivalent to "int". This results in the amusing behaviour of the compiler accepting "unsigned short" (equivalent to "unsigned" or "unsigned int"), but rejecting "short int" (because it looks like "int int"). I'd be interested in knowing whether this happens in real V7 compilers, or only in BBN's. -- Morris M. Keesan {decvax,linus,wjh12,ima}!bbncca!keesan keesan @ BBN-UNIX.ARPA