-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
no obvious answer.
May I bash my head against the wall? :)
Sure, it's a free world!
The struct declaration places an obligation on the compiler to provide an *externally* visible relationship between &b and &b.a; thereby letting &b escape out of the compiler's omniscience. If b.a is fair game for g to modify, then so is b itself - otherwise, why bother having an ABI?
And, that's exactly why there's controvery here. Your point of view is resaonable. So are other points of view, even though many people seem convinced that theirs is the only reasonable one. :-) Nick's paper in fact refers to this; he points out that many people say that everyone knows what is meant -- but that they don't agree on what is meant. :-)
If you allow the compiler to assume that *only* b.a gets modified (along with any other global variables), then what will that compiler do with:
void g(char const *);
void f(char *s) { char const *fred = "fred walks"; *s = 'f'; g(s); }
Will you allow that compiler to "optimize" that to:
void f(char *s) { g("fred walks"); }
Well, there are bugs in your example, in that string constants are read-only... But, no that's different from the case being shown in that there is no possibly-invalid pointer arithmetic.
If you take away the "..." preceding your "struct A a;", then immediately all of glib, GTK+, etc. break.
Yes, and that's why some people are proposing a special first-member exception.
Anyhow, I think consensus is evolving towards enabling this optimization only when explicitly requested, so you need not be concerned.
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
