"UB should not be taken literally as "you can do anything". To take this to an extreme, a compiler that deletes any source files that contain UB could be compli

"UB should not be taken literally as "you can do anything". To take this to an extreme, a compiler that deletes any source files that contain UB could be compliant, but would also be one that no one ever wants." While I would agree it should not be taken as "you should do anything", I disagree with the notion that it should not be taken as "you can do anything". For the situations I use C and C++ in: 1) I'm simply not willing to pay the price to catch all potentially dangerous UB at build time. My build times are bad enough as is without forcing a full static analysis pass during every iteration, and those still have holes and false positives. The laws of physics prevent us from paying some currently unimplemented O(N^crazy) checks that would certainly catch some bugs... and O(N^3) is bad enough, from what I hear. 2) I'm simply not willing to pay the price to mitigate all potentially dangerous UB at run time. I already spend more time optimizing than I'm happy with - making the compiler do less means I'll have to do more, which has an opportunity cost: I'll have less time to hunt down non-UB dangerous code. As such, I'm happy to have ASLR and NX bits, but I won't be turning off my optimizer nor enabling the more paranoid compiler-generated bounds checking. If this means a malicious attacker manages "rm -f /home/user/project/all-my-undefined-code.c" through a buffer overflow rather than unsanitized input strings, so be it. "It's also worth mentioning that the "UB = optimisation" advocates seem to be mostly academics with an intense interest in replacing C with "safer" languages... and there's no better way to further their own agenda than to "legally" disparage C and make it a worse language than it should be." I have an interest in replacing C with "safer" languages - specifically the kind that can better do safety and speed simultaneously. I feel that neither C nor C++ can be twisted much further towards those goals efficiently, without fundamentally redesigning those languages to the point where they're... well, no longer C nor C++.