Correction, a[33]

[Karl Heuer]

In article <17763 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>In article <5819 at microsoft.UUCP> microsoft!t-iaind (Iain Davidson) writes:
>>[incorrectly states that char a[33] has 34 elements.]

Prepare for a flood of replies.  Time to update your kill files, folks.

>Actually, there is a grain of truth in all this.  Given an array declaration
>	T a[N];
>the address &a[N] must be computable.  This sometimes means that
>array objects need an extra byte---so that
>	int b[K];
>actually sets aside K*sizeof(int)+1 bytes, rather than just K*sizeof(int).

This is true, but could be misleading to much of the audience, so I'll
rephrase it.  It is required that the overlast element of the array be
addressible, but there need not be any storage reserved for it, unless this is
necessary for addressiblity.  For example, given two declarations
	int a[4];  int b[7];
it is perfectly legal for the compiler to allocate exactly 11*sizeof(int)
bytes, and to have &a[4] be the same address as &b[0].

Similarly, &b[7] could legally be at the end of memory, pointing to nothing
dereferencable; all that's required is that &b[7] can be computed and stored
in a pointer variable (and that the usual laws of pointer arithmetic are
obeyed).  On some architectures, the end of all memory (or of a segment) does
not satisfy this rule; in this case only, the compiler must insert a shim.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
(Btw, there is no reason to suppose that a and b are adjacent in memory, or
that a precedes b.  That was just an example of a legal implementation.)