henry@utzoo.uucp (Henry Spencer) (12/17/89)
In article <1159.258b86f8@csc.anu.oz> bdm659@csc.anu.oz writes: >"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 see any reason why a byte must follow the object. An implementation >could easily make a special case in the internal representation... The quoted text would perhaps be better phrased as "This stipulation imposes no penalty worse than requiring that every object be followed by one byte whose address is representable." I don't see any demand that there be such a byte, just a rather clumsy wording of explanatory material. -- 1755 EST, Dec 14, 1972: human | Henry Spencer at U of Toronto Zoology exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bdm659@csc.anu.oz (12/17/89)
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)