🚀 go-pugleaf

This is getting repetitive, but I think I do have to say it once more.
I assume everyone knows the context by now.

> There is a difference.  The p in my original posting pointed to a
> single char *in the array returned by malloc*.  The decayed f->s, on
> the other hand, points to a single char in the array f->s.

There is no difference.  The standard says (in 3.1.2.5 = 6.1.2.5) that
a pointer provides a reference to the pointed-to type.  It does not say
that it carries any additional information.  We agree that p and the
decayed f->s point to the same char.  This char is in the array f->s,
and also, *simultaneously*, in the array returned by malloc.

> All of the justifications for allowing this hack have been based on
> the fact that the pointer was returned by malloc.  This is, however,
> not the case; f->s was *not* returned by malloc.  It is a one char
> array, which degenerates to a pointer into *this* array (and only
> co-incidentally, into the array returned by malloc), and thus, the
> results of accessing further char's behind the one declared are
> undefined.

It is *not* coincidental, which is exactly the point.  The pointer,
either p or the decayed f->s, points into the array returned by malloc
*because we made it do so*, using only operations allowed and defined
by the standard, and because we took advantage of the fact that a pointer
does *not* contain information as to how its value was derived.[1]
Therefore the access in question is valid.

[1] More precisely, a strictly conforming program mustn't be able to
tell if it carries such extra information.  Due to the "as if" rule,
a bounds-checking implementation is free to attach extra information
to pointers and use this information only to detect undefined accesses.
It could even issue a run-time warning if you used the "struct hack";
the standard never prohibits warnings.  But it must not *prevent* the
"struct hack" from working, since it is valid; if bounds information
could be used to terminate the program, then the bounds attached to
the decayed f->s must be those of the array returned by malloc.  In
practice I think it is easier for such an implementation to attach
the bounds to the arrays rather than the pointers, and with each
pointer to carry the information of what array it is pointing into;
then both f and the decayed f->s can be identified as pointing into
the array returned by malloc.
-- 
Mark Brader		  "We may take pride in observing that there is not a
SoftQuad Inc., Toronto	   single film showing in London today which deals with
utzoo!sq!msb		   one of the burning issues of the day."
msb@sq.com		      -- Lord Tyrell, British film censors' chief, 1937

This article is in the public domain.