🚀 go-pugleaf

msb@sq.sq.com (Mark Brader) writes:

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

We seem to have some circular reasoning here.

I proposed an implemention which I claimed was conforming on which
the struct hack would not work; therefore the struct hack is illegal.

Mark claims the struct hack is legal; therefore the proposed
implementation is not conforming.

I think we need to show that the proposed implementation is non-
conforming or that the the struct hack is not strictly-conforming by
appealing to the language of the standard.

I remain unconvinced that the struct hack is strictly conforming,
completely apart from the possibly flakey implementation I proposed.

For example, if the struct hack is strictly conforming, what about this:

	struct S {
	    double a[2];
	    double b;
	} s;
	s.a[2] = 1.0;

The array reference exceeds the declared bounds of s.a, but not the
bounds of object s, because sizeof(s) can't be smaller than
sizeof(a)+sizeof(b).  If a compiler can't add padding to the end of
the struct for other than alignment, then surely it can't add padding
between a and b, because it can't be required for alignment.  Therefore
s.a[2] must be the same as s.b.

I don't buy this reasoning, and it seems to me it is no different
from the struct hack.  I claim that both this example and the
struct hack are not strictly conforming, because the declared bounds
of an array are exceeded.  Probably both examples will work on any
typical implementation, however, which is a separate issue.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com