Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!boulder!cu-den!udenva!isis!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.lang.c
Subject: Re: Is &a[NTHINGS] legal (and the shim)
Message-ID: <4554@ico.ISC.COM>
Date: 3 May 88 06:02:19 GMT
References: <12074@tut.cis.ohio-state.edu> <11289@mimsy.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 38
Summary: is shim needed?  (implications for the nasty 286!)

In article <11289@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> (Lawrence V. Cipriani) writes:
> >Is it legal to apply the & (address of) operator to an array
> >element that is non-existent?
...
> Yes.  If necessary, the compiler will put a one-byte (or word or
> whatever) shim after the array in that array's address space, so
> that &a[NTHINGS] will be meaningful.

Chris, is this really so?  I understand that &a[NTHINGS] should be valid,
but I don't see why the shim is necessary.  It seems that all you require
is that the address be meaningful and produce correct results on a com-
parison--you can't dereference it because it doesn't exist.

For example, on the 286 (an all-too-frequent counterexample) you can have
contiguous objects up to 2^16 bytes without too much hardship--and since
it is often useful to have arrays of size power-of-two, you might like to
declare, say
	char stuff[65536];
or
	int nonsense[16384];
but you would certainly NOT want the compiler to try to allocate 65537 or
65540 bytes--that just won't work in the normal universe (large model or
less).  There's no reason it should try to do so, however.  It can form an
address &stuff[65536] which is usable for comparison--and address
arithmetic--even though it's not a valid address (nor even a valid segment,
for that matter).

However--here, 286 compiler folks take note--it does require treating
pointer comparison as a 32-bit operation for <, <=, >, >= (not just == and
!=).  The object "stuff" might have an address that looks like 008f0000.
The address of stuff[65535]--the last element--is 008fffff.  The next
valid user-space address (assuming sequential allocation of segments) after 
008fffff is 00970000.  A straightforward calculation of &stuff[65536] will
give 00900000--not a valid address; gives a protection violation from a
user program--but useful for a 32-bit unsigned comparison.
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...Never attribute to malice what can be adequately explained by stupidity.