[uecker]

Those ideas are not convincing. Consider the glibc bug from yesterday. If I understood it correctly, there is an integer overflow causing a heap overflow. The integer overflow was unsigned wraparound - so fully defined behavior. So no, we do not want latent bugs remain latent. We want UB sanitizers and checkers and fix all this crap.

[aw1621107]

I think that's arguably a distinct concern from what boringcc/friendly C are intended to address. My understanding is that the latent bugs those are intended to keep are those that would be unearthed by aggressive exploitation of UB. Sanitizers/checkers/etc. would still be useful iirc boringcc/friendly C for finding bugs arising out of fully-defined behavior.

[uecker]

Sanitizers / checkers are much useful if the behavior is defined, because you can then not be sure it is not intentionally used in the way allowed by the definition. So you can not check at run-time in production and stop the program but you can with UB and during testing you would need to analyze each case individually.

[aw1621107]

I think sanitizer usefulness for defined behaviors is going to depend a lot on how frequently those behaviors are intentionally used and how easy/hard it would be to suppress false positives.

There might be some behaviors that sanitizers don't currently catch but are used for optimizations as well, and boringcc/friendly C might be useful for those? Not entirely sure what those might be, if they even exist, though; IIRC sanitizers don't currently flag strict aliasing violations, but -fno-strict-aliasing exists so there's no need for a new compiler/dialect (for GCC/Clang?)