🚀 go-pugleaf

In article <1993Jan8.065947.29719@sq.sq.com>, msb@sq.sq.com (Mark
Brader) writes:
|> > ... Again, the basic question is still unresolved here: can a conversion
|> > from one pointer type to another affect bytes other than those
|> > where the pointer variable is stored?
|> 
|> There is nothing in the standard to justify such an action, so it
|> would be permissible only under the "'as if' rule".  It could, for
|> example, modify bytes that the program mustn't read because the
|> behavior would be undefined, such as the bytes of an object of
|> indeterminate value.  It could modify the bytes of a volatile object.
|> But it could NOT modify some arbitrary object with a well-defined
|> value that the program correctly expects to persist!

Agreed, so far.

|> 
|> In particular, it could not modify padding at the end of a struct,
|> precisely *because* it would break the struct hack.

Ok. Finally we have the explanation: the struct hack is legal, because
otherwise it would be illegal. :)

Here is another explanation, why the compiler cannot add this kind of
type-check
information:  Malloc can (and often does) allocate a whole array of structures.
It cannot write the information to the end of *all* the structures (since it
does not know the number of elements).  The only solution would be to write
the information whenever a new pointer value to one of these structures
gets created (via casting, assignment AND POINTER ARITHMETIC).  But then there
is no point in keeping this information at all (because the whole idea was to
*probe* this information instead of freshly generating it).

(More objections, Dave?)

-Matthias