&gt; On strict aliasing, I&#x27;m against it without explicit opt-in over a delimited subset of source code. I understand that using &amp; is going to harm the performance of my code; I think that&#x27;s an acceptable tradeoff for more predictable behaviour.<p>I believe that you and others think that&#x27;s an acceptable tradeoff. At the end of the day, though, most people want C compilers to produce the fastest code possible. Compiler authors are just responding to what users want. The example below is actually an excellent example of this.<p>&gt; If it harms the performance of C++ vector iterators, for example, I don&#x27;t care: strict aliasing rules are a worse cure than the disease of C++&#x27;s poorly thought out abstraction tools.<p>It&#x27;s not just C++. Consider (from Chris Lattner&#x27;s blog post):<p><pre><code>    float *array;
    void zero_out() {
        for (int i = 0; i &lt; 100; i++)
            array[i] = 0.0;
    }
</code></pre>
People saw compilers missing the optimization to compile this to a memset, and filed bugs against them. As a matter of fact, though, that is an illegal optimization to make unless the compiler is able to take advantage of strict aliasing. That&#x27;s because, absent strict aliasing, array[0] could legally be a type-casted pointer back to &quot;array&quot; itself, even though almost nobody would actually write that code.<p>The reason why compilers implemented strict aliasing rules is that their users demanded that they fix &quot;optimizer bugs&quot; like the one above. And, honestly, I can&#x27;t blame either the compiler developers or the users. Strict aliasing ends up being one of the things that&#x27;s often important for performance. The problem, if anything, lies with the C language.