Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: Correction, a[33] Message-ID: <13434@haddock.ima.isc.com> Date: 26 May 89 19:48:13 GMT References: <5819@microsoft.UUCP> <17763@mimsy.UUCP> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Distribution: usa Organization: Interactive Systems, Boston Lines: 30 In article <17763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <5819@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@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.)