Most the confusion that I've seen in discussions of
strict aliasing rules has come from developers thinking
that strict aliasing is a set of rules telling them how
to do type punning within the restrictions of the
standard. It's not about that at all. Instead it's a
set of rules telling compiler writers when they can't
do some optimizations. Of
course developers who do type-punning do need to under-
stand these rules to make sure that their code doesn't
break in the presence of optimization.
I've written a first draft of a short little paper on
this that I hope can be referred to whenever confusion
arises again. The audience is really developers who
use the compilers because the compiler writers already
understand this. Nevertheless, I've seen compiler
writers and others who work on standards bodies in
conversations where they just couldn't understand
why communication was not happening. They would
benefit from reading the introduction.
http://dbp-consulting.com/StrictAliasing.pdf
Some of it is derivative of the stuff I wrote on
the boost developers wiki about it, but in this I talk
a lot more about what strict aliasing is.
I'm hoping people here who understand the issues will
read it and email me with any corrections, examples,
improvements etc. I'm really hoping that someone in
gcc development might donate a paragraph about how and
why it's hard to warn about this. I don't have
anything about that yet, but it's an important issue.
I've often seen people upset/confused/deranged
because someone gives them an example of something
that violates the aliasing rules, but gcc (or
another compiler) doesn't warn about the example
at all. It makes them doubt the truth of the
example. They need something to help them
understand so they can feel all warm and comfy;)
Perhaps something else about how using unions
instead of casting to incompatible types gives the
compiler information that lets it generate better code.
Thanks for your time,
Patrick
