On Fri, Nov 18, 2011 at 11:27 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
[1] -Wstrict-aliasing is one of these cases.
The spots such warnings point to, often are broken, but not always,
because GCC has difficulties in identifying these.
This use to be more true, but there are multiple levels of -Wstrict-aliasing and
I would be _highly_ surprised if the default gave a false alarm. I think you
can reliably say that if you get a warning at the default level then you do
have a language standards conformance problem, and that it actually changes
the generated code... but maybe you don't actually crash on any
particular system.
I don't think 'the code is objectively wrong in a meaningful way' is a
false alarm.
I've seen code that miscompiled and crashed due to violating the aliasing rules
but only threw a warning at higher levels. It's arguably too
conservative already.
If GCC is sure something is wrong, it is supposed to raise errors.
This isn't true. E.g. you can write code which reads and uses
uninitialized memory
where the compiler is _absolutely sure_ of it. You still just get a warning. The
compiler would be compatible with the spec if it replaced this program with
system("rm -rf /"), but you only get a warning.
I quote the manual: "Errors report problems that make it impossible to
compile your program."
(Though I agree with your view wrt the unfortunateness of
style-warnings ("omg you used a
^ without fifty parentheses") being hard to separate from ones where
the compiler knows
that your code is broken.)