Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!husc6!necntc!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.lang.c Subject: Re: standardizing integral type sizes Message-ID: <3162@jade.BERKELEY.EDU> Date: Mon, 13-Apr-87 23:17:27 EST Article-I.D.: jade.3162 Posted: Mon Apr 13 23:17:27 1987 Date-Received: Wed, 15-Apr-87 05:18:23 EST References: <101@umich.UUCP> <791@xanth.UUCP> <1987Apr9.155110.28398@sq.uucp> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 47 In article <1987Apr9.155110.28398@sq.uucp> msb@sq.UUCP (Mark Brader) writes: >The second thing is, yes, efficiency. The Draft Standard DOES specify >MINIMUM ranges for the different types. In effect it guarantees... > > char <= short <= int <= long > char >= 8 bits, short >= 16 bits, int >= 16 bits, long >= 32 bits > >... with the further presumption, which has been part of C for a long >time, that int operations are at least as efficient as other types. Unfortunately, these are only specified by implication (so far as I can tell). If someone can provide a paragraph number, where all of this is specified (or anywhere where "int operations are at least..." is specified), I'd appreciate it. >then your compiler will give you what you really need in the way most >suited to WHATEVER machine you may run on. Now how can you do better >than that? Something that did what you said. For instance, consider a hypothetical Queer Machine for C (QM/C), which has 18 bit words (word addressed), and instructions for dealing with double words. The obvious implementation has int = short = 18 bits, and long = 36 bits. Now, supposed I need 16 bits of magnitude on a signed value. For this machine, declaring things as int works just fine. But the program will not work on "standard" machines, because it really wants longs for that value. But if I declare things as "long," I chew up twice the space for storage, and presumably more time. In other words, following your advice doesn't get me what I really need, and does it a way incredibly inappropriate for QM/C. >Well, the world is not quite as perfect as I am implying here. If you >require variables exceeding 32 bits, your code is certainly nonportable >whatever you do, because no variable is guaranteed such accuracy. True. It would be nice if I could declare things so that the program would break at _compile_ time. There's actually an easy way to do this, at zero cost to those who don't need bit-level control of their data types.