🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #6119

Pointers (and objects?) just after an array object.

#6119
From: bdm659
Date: Sun, 17 Dec 1989 12:30
54 lines
3174 bytes
c.anu.oz>
Followup-To: .anu.oz>

Organization: Computer Services, Australian National University
Lines: 48

[Slightly expanded version of an article might apparently didn't make it.]

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.

I have another problem concerning &A[N].  Section 3.3.6 of the Rationale 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."

The same claim can be found in footnote 43 in 3.3.6 of the Standard, which
is perhaps more serious as the footnotes generally can't be ignored (despite
being officially not part of the Standard).

[Incidentally, it is not the case that "every object" should be "every array
object", as a pointer to an ordinary object can be treated as a pointer to an
array of size one for most purposes (stated several times in Section 3.3.)]

I don't see any reason why a byte must follow the object.  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 (example: 3.3.9).

========================================
Brendan McKay.   bdm@anucsd.oz.au  or  bdm659@csc1.anu.oz.au
terrorist: n. an individual who behaves like a government  (original)
Technical Details
Message-ID: <1159.258b86f8@csc.anu.oz>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!csc!bdm659
References: <448@longway.TIC.COM> <450@longway.TIC.COM> <15364@haddock.ima.isc.com> <809@prles2.UUCP> <1989Dec8.161820.24804@jarvis.csri.toronto.edu> <1989Dec11.181631.3864@jarvis.csri.toronto.edu> <465@cpsolv.UUCP> <11809@smoke.BRL.MIL> <1147.2588ce34@cs

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!csc!bdm659
From: bdm659@csc.anu.oz
Newsgroups: comp.std.c
Subject: Pointers (and objects?) just after an array object.
Message-ID: <1159.258b86f8@csc.anu.oz>
Date: 17 Dec 89 12:30:48 GMT
References: <448@longway.TIC.COM> <450@longway.TIC.COM> <15364@haddock.ima.isc.com> <809@prles2.UUCP> <1989Dec8.161820.24804@jarvis.csri.toronto.edu> <1989Dec11.181631.3864@jarvis.csri.toronto.edu> <465@cpsolv.UUCP> <11809@smoke.BRL.MIL> <1147.2588ce34@cs
Lines: 54