1) Challenges in understanding undefined behavior are exactly why tools like ubsan[1] exist.  In a way they help &#x2F;everyone&#x2F; understand when &#x27;undefined&#x27; constructs are encountered, and having this emitted by the compilers responsible for translating your source code into binary code is the ideal place.<p>2) Compilers leveraging undefined behavior knowledge get a lot of hate for breaking this implicit contract defining what they &quot;should&quot; do as expected by programmers.  Unfortunately these feelings are rather misguided, compilers are just doing what they can to produce the best code for you using the explicit contract that exists: the language specification(s).  Are these specifications perfect? No, but they&#x27;re what we have.  If someone were to define a new language that actually captures the assumptions &quot;real&quot; programmers &quot;expect&quot; when they write code then compilers could choose to support it (and probably would!) and everyone would be happier.  Until then this is a big case of &quot;how come you&#x27;re not doing that thing you never said you&#x27;d do and no one is willing to define properly?&quot; which is a bit silly.  Imagine you&#x27;re a compiler developer: what assumptions CAN you make to satisfy everyone? In short, compiler developers aren&#x27;t your enemy, they&#x27;re just doing everything they can to produce the best code they can for you.<p>2a) Use of -f* is in a way used to define that a special variant of a language is desired, for example -fwrapv builds the code using an unnamed variant of C where signed integer overflow is well-defined.<p>[1] <a href="http:&#x2F;&#x2F;clang.llvm.org&#x2F;docs&#x2F;UndefinedBehaviorSanitizer.html" rel="nofollow">http:&#x2F;&#x2F;clang.llvm.org&#x2F;docs&#x2F;UndefinedBehaviorSanitizer.html</a>