I agree that&#x27;s a pretty good example the other way.<p>I&#x27;m pretty sure your snippet invokes nasal demons in all dialects. Dereferencing NULL is a pretty classic case where anything can happen once you do it. &quot;Calling launch_missiles even though you don&#x27;t want it to happen&quot; is a subset of &quot;anything,&quot; of course.<p>Consider what happens if you rearrange that example a bit, though. Let&#x27;s say it&#x27;s more like this:<p><pre><code>    int computation(int *ptr_a, int *ptr_b) {
        if(ptr_a == NULL &amp;&amp; ptr_b == NULL) return 0;
        if(ptr_a == NULL) return val_b;
        if(ptr_b == NULL) return val_a;
        launch_missiles(); &#x2F;* OK to put this here? *&#x2F;
        return ...something with val_a and val_b...;
    }

    int otherComputation(int *ptr_a, int *ptr_b) {
        int val_a = *ptr_a, val_b = *ptr_b;
        int intermediate = computation(ptr_a, ptr_b);
        return ...something with val_a, val_b, and intermediate....;
    }
</code></pre>
Then you call otherComputation in a tight loop. Should the compiler elide the NULL checks here, if computation gets inlined? otherComputation clearly requires that its parameters are non-NULL, so it should be fine to remove the checks. Failing to do so would be pretty annoying. It&#x27;s clear that the inputs are constrained, and while you could fix it by factoring out the common code so that the NULL checks are explicitly optional, it would be best if the optimizer can handle it and not require us to rearrange our code to make it happy.<p>That&#x27;s really what I&#x27;m getting at. There are clear examples where it&#x27;s bad to assume undefined behavior cannot happen and optimize away checks. But there are also clear examples where it&#x27;s exactly what you want to do. Can the optimizer reliably distinguish between these cases?<p>I think the best answer is to have tools available like the undefined behavior sanitizer which can catch these problems at runtime. You want the optimizer to make your code as fast as it legally can. Trying to tone it down is going to be error-prone, and safety checks that can&#x27;t be counted on are dangerous. You might end up just moving the problem around: instead of code suddenly being optimized out because the compiler proved it can&#x27;t run without invoking undefined behavior, you&#x27;ll have code suddenly being optimized out because something changed that made the compiler think you intended it. By checking at runtime, you recast the problem from &quot;does the programmer intend to pass in values which will result in undefined behavior?&quot; to &quot;does this code <i>actually get called</i> with such values?&quot; That&#x27;s way easier to check, should have zero false positives, and should have as few false negatives with good test coverage.