Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!steinmetz!davidsen From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: pointer alignment when int != char * Message-ID: <6706@steinmetz.steinmetz.UUCP> Date: Wed, 15-Jul-87 13:00:49 EDT Article-I.D.: steinmet.6706 Posted: Wed Jul 15 13:00:49 1987 Date-Received: Sat, 18-Jul-87 00:47:09 EDT References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) Organization: General Electric CRD, Schenectady, NY Lines: 49 Xref: mnetor comp.lang.c:3068 comp.unix.wizards:3259 In article <6110@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) writes: >In article <6655@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: >>Why not have int be 32 bits? That fits the requirement that >>length char<=short<=int<=long. Not a comment, just a question... > >There are two main considerations for the correct size to be used for (int) >when implementing C on a new system: > >1. (int) objects should be accessible quickly. On a word-addressed >architecture, this argues for making them full words. [ I thought you mentioned that the 32 bit size was hardware supported. On many machines the short math is faster than long (ie. vax, 68000). ] > >2. (int)s must be usable for indexing arrays. Depending on the address >space, one may have to either impose an artificial limit on array sizes >or else make (int)s longer than they might have been. For example, on [ The 32 bit size allows an acceptable range as a subscript, although at some point 4GB won't be enough, most of the problems using big memory are also using multiple arrays less than 2GB. ] >I understand from hearsay that the IBM PC world (actually the Intel 8086 >world) ran against this very problem, and instead of making a single sane >choice they ended up proliferating a variety of incompatible sets of >choices (hilariously called "models"). One hopes that a lesson was learned, >but I doubt it. That's the point I was making in my posting... the problems occur when the int won't hold an address, and then mainly because some is playing fast & loose with bit fidling in pointers or some such. The major problems with "models" would go away if someone made the large model int the same length as the large model pointer. I've been fighting with this in pathalias, trying to get it to run on an 80*86 machine, and finding that (a) it does all its own memory allocation, and (b) it uses ints to hold addresses while doing it. This kind of non-portable code will fail on machines which are not byte addressed, and which use a pointer which looks like a word address and character offset. X3J11 covered this very well, pointers are not forced to be the size of int, they are not even the size of each other! Code written for large model 80*86 will almost always run on any other machine, assuming that it doesn't use calls to the hardware, etc. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me