Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Newsgroups: comp.lang.c Subject: size of int & the 68K (was: standardizing integral type sizes) Message-ID: <3217@jade.BERKELEY.EDU> Date: Sun, 19-Apr-87 00:52:32 EST Article-I.D.: jade.3217 Posted: Sun Apr 19 00:52:32 1987 Date-Received: Sun, 19-Apr-87 17:48:10 EST References: <101@umich.UUCP> <791@xanth.UUCP> <1987Apr9.155110.28398@sq.uucp> <652@edge.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 47 >I bring this up because on the C compilers I've used on the 68000, "int" >has always been a 32-bit quantity. This is almost a necessity, because >of the well-known bad habit of assuming that a pointer will fit in an int. I've worked with 68K C compilers that had 16 bit ints. I've also worked with 68K C compilers that had 32 bit ints. I cussed at the first when porting code, and the second when writing code. As far as I'm concerned, the correct solution for the 680[01]0 is to provide both, with a compiler flag to get the "odd" one. In any case, some kind person provided: >Well, I did say "in effect". I guess you want the actual wording. >Section 3.1.2.5 reads in part... > ># There are four types of signed integers, called signed char, short int, ># int, and long int. ... ># ># A signed char occupies the same amount of storage as a "plain" char. ># A "plain" int has the natural size suggested by the architecture of the ># execution environment. ... The set of values of each signed integral ># type is a subset of the values of the next type in the list above. > >This covers the first set of inequalities and the efficient-ints rule. I disagree. "natural size" is not the same as "most efficient size." For instance, a C compiler generating code for a 68K running Tripos should use 32-bit ints, as that's the natural size for that environment. But 16-bit ints are still the most efficient [and what I'd rather have the compiler generating!] And Henry Spencer says: >It loses us the current semantics of "int", which are "the form of integer >that is most efficient on the machine in question". Since most well-written Henry, can you provide a paragraph number in dpANS that says that? Or a page/paragraph number from K&R. I agree that that's what it _should_ be, but haven't been able to find anything to prove it. Please note the above on dpANS paragraph 3.1.2.5. Thanx,