Proposed resolution to aliasing issue.

[Mark Mitchell]

Bernd Jendrissek wrote:
> -----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
mark@codesourcery.com
(916) 791-8304