Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> int f() {
> a_union t;
> t.d = 3.0;
> return t.i;
> }
>
> The practice of reading from a different union member than the
> one most recently written to (called "type-punning") is common.
> Even with `-fstrict-aliasing', type-punning is allowed,
> provided the memory is accessed through the union type. So, the
> code above will work as expected. However, this code might not:
>
> int f() {
> a_union t;
> int* ip;
> t.d = 3.0;
> ip = &t.i;
> return *ip;
> }
This looks insane. Am I misreading it, or does it really say that
`*(&t.i)' is different than `t.i'? Also, why should union type
variables be any different than other variables in this regard? For
instance:
int f() {
int a;
int *ip;
a = 10;
ip = &a;
return *ip;
}
How is this any different than what is done above?
> "everybody has fixed their code already because other compilers have
> been doing this optimization for ages"
If the last is really the case, then we indeed have nothing to worry
about. XEmacs has compiled and run on non-Gcc compilers for ages.
*If* the last is really the case.