mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (04/19/87)
>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, <mike -- Here's a song about absolutely nothing. Mike Meyer It's not about me, not about anyone else, ucbvax!mwm Not about love, not about being young. mwm@berkeley.edu Not about anything else, either. mwm@ucbjade.BITNET
henry@utzoo.UUCP (Henry Spencer) (04/29/87)
> >It loses us the current semantics of "int", which are "the form of integer > >that is most efficient on the machine in question". ... > > 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. Without having searched them carefully, I would say that there probably isn't anything that spells it out precisely. There are all those comments about ints being the "most natural" size, and certainly "most efficient" is what most people take that to mean (modulo the problems on the 68000). -- "If you want PL/I, you know Henry Spencer @ U of Toronto Zoology where to find it." -- DMR {allegra,ihnp4,decvax,pyramid}!utzoo!henry
dlnash@ut-ngp.UUCP (Donald L. Nash) (05/01/87)
In article <7981@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > >It loses us the current semantics of "int", which are "the form of integer > > >that is most efficient on the machine in question". ... > > > > 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. > > Without having searched them carefully, I would say that there probably > isn't anything that spells it out precisely. Look in K&R p.34: int an integer, typically reflecting the natural size of integers on the host machine. I don't know what dpANS has to say about it, since I don't have a copy. Don Nash UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash ARPA: dlnash@ngp.UTEXAS.EDU BITNET: CCEU001@UTADNX, DLNASH@UTADNX TEXNET: UTADNX::CCEU001, UTADNX::DLNASH