Re: GCC aliasing rules: more aggressive than C99?

[Patrick Horgan <phorgan1@yahoo.com>]

Andrew Haley wrote:
> On 01/03/2010 05:46 AM, Joshua Haberman wrote:
>   
>> ...elision by Patrick...
>> To me this allows the following:
>>
>>   int i;
>>     *pu = (union u*)&i;
>>   printf("%d\n", pu->x);
>>     
>
> I do not believe that this is allowed.  A union of type
>
>    union u { int x; }
>
> is not compatible with the type int.  It might have greater alignment,
> it might be larger, and so on.  
It couldn't have different alignment since the member has to have the 
same alignment it would usually have and padding at the beginning of a 
union is not allowed.  They are certainly layout-compatible types.   I'm 
not sure about larger, why would a compiler add padding to the end?  In 
the C++ spec it couldn't, since they don't have the clause about being 
able to add padding at the end.  Certainly in gcc the size is the same.  
The standard doesn't specify anything about this other than the size 
must be sufficient for the largest member, and that padding may be added 
at the end.  What do you mean by and so on?  Not trying to be 
argumentative or anything, but now I've gotten intrigued.  It's interesting!
> We do know that a pointer to a union
> can be converted to a pointer to each of its members and vice versa.
> But, and this is crucial, *that does not mean they are compatible
> types*.
>   
A pointer to union and a pointer to int are not required to have the 
same representation.   But what about printf("%d\n", (*((union 
u*)&i)).x);  That bypasses the issues about pointers entirely.  I know 
it's silly code, but it seems to fit the aliasing rules. gcc doesn't 
warn about it even with -Wstrict-aliasing=3 and -fstrict-aliasing, nor 
does g++ warn about an equivalent program using cout instead of printf.

Patrick