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