Re: dereferencing type-punned pointer will break strict-aliasingrules

[Alexander Malmberg]

Frederic De Jaeger wrote:
> 
> Nicola> Ok.  I have added -fno-strict-aliasing to fix the short term 
> situation,
> Nicola> but I suspect it might be a compiler bug, and in the long term it 
> would be
> Nicola> much better to fix the compiler.
> 
> It's not a compiler bug.  It is a C99 bug, or more exactly, a
> feature.  C99 changed the semantic of the C language with respect to
> aliasing questions.   Now, the compiler can assume that pointer to
> different types points to different memory location.  This breaks all
> the OO code written in C.

In c? Probably, although it depends on how you write the oo code. In
objective-c code, for aliasing purposes, pointers to different classes
should probably be considered to be of the same type, and I suspect that
this is handled by gcc since it doesn't seem to give any warnings about
that.

> This is a very good idea that the compiler issues a warning message
> because the semantic of language really changed and you want to revert
> to the old semantic.
> 
> The make package MUST add -fno-strict-aliasing.  It is not a
> convenience to get rid off warnings.

The problem is that, afaict (I don't actually have gcc 3.3, so I haven't
been able to test it myself), the code generated by the objective-c
frontend for @selector() expressions, including those implicit in
message sends, breaks the aliasing rules (or triggers the aliasing
checks later). Thus, in this case, it is a convenience: the compiler is
warning about code generated by the compiler itself.

- Alexander Malmberg