🚀 go-pugleaf

In article <11809@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <465@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>>In article <1989Dec11.181631.3864@jarvis.csri.toronto.edu> norvell@csri.toronto.edu (Theo Norvell) writes:
>>>int A[N];
>>>&A[N] /* Undefined! */
>>I think some special language might be required in 3.3.6 to allow &*
>>without undefined results, since this is probably what the committee
>>desired anyway.  It would be silly to allow A+N but not &A[N]!
>
> I seem to vaguely recall discussion of this point in some X3J11 meeting,
> and it is not clear to me whether or not &A[N] being undefined was
> intended or not.  This is another case where an official query should
> be sent to X3.
>
> For people who didn't follow the argument, &A[N] is equivalent to &(*(A+(N)))
> but *(A+(N)) is a semantic violation.  (A+(N)) is okay, but applying * to
> it is not okay.

Section 3.3.6 in the Rationale (Dec. 1988 version) has an example using
&A[N], so at least one member of the committee thought it was ok.  On the
other hand, that part of the Rationale is up the creek in another way.
It says

"This stipulation [allowing a pointer to point just after an array] merely
requires that every object be followed by one byte whose address is
representable."

I don't think that follows at all.  An implementation could easily make a
special case in the internal representation of a pointer to cover the
case where an array ends at the end of addressable memory, or at the end
of a memory segment, if it wanted to.  I don't see anything in the Standard
which says that a pointer just past the end of an array must be a pointer to
an object.  In fact, in places it is clearly distinguished from pointers to
objects.

Brendan McKay.   bdm@anucsd.oz.au  or  bdm659@csc1.anu.oz.au