On Sat, 20 Jan 2007, Christian Biere wrote:
> This is from gcc(1):
> 
> union a_union {
> 	int i;
> 	double d;
> };
> 
> int main(void)
> {
> 	union a_union t;
> 	int* ip;
> 
> 	t.d = 3.0;
> 	ip = &t.i;
> 	return *ip;	
> }
> 
> Even though the manpage says this code might not work as "expected"
> (whatever one would expect here), I can't convince it to warn about
> this.

"Might not work as expected" apparently means "might not work like the
previous example", which was almost identical, except it returned t.i
directly instead of indirecting through a pointer.

In the previous example:

        int f() {
	  a_union t;
	  t.d = 3.0;
	  return t.i;
        }

the "expected" result is that the bit pattern representing (double)3.0
is accessed as if it was a bit pattern representing an integer, and
that integer is returned.  This is called "type punning".  Because this
is done explicitly through a union, the compiler is supposed to make it
work.

In the example you referred to:

        int main(void)
        {
          union a_union t;
          int* ip;
        
          t.d = 3.0;
          ip = &t.i;
          return *ip;	
        }

the compiler is allowed to think "Hmm, there are no pointers to double
or pointers to "union a_union" anywhere in sight, and t is not used
after the assignment to t.d, therefore there is no legal way for the
program to use the new value of t.d, therefore the assignment to t.d
doesn't really need to happen".  This sort of optimisation is allowed
because the program is violating the "shall" clause in section 6.5
paragraph 7 of the C99 standard ("An object shall have its stored value
accessed only by an lvalue expression that has one of the following
types [...]"). The lvalue expression *ip is not of a type that is
allowed to be used to access a double object (such as t.d) or a union
a_union object (such as t).

--apb (Alan Barrett)