> What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of t

> What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. I'm not sure how much I agree with this. I agree that compilers have gotten a lot better about deriving information from UB analysis in the past decade or two, but I think a lot of the time it gains information from the additional analysis rather than ignoring existing information. The main example I can think of for a compiler ignoring information from the source code is strict aliasing, where the compiler can ignore the fact that two addresses can be statically proven to point to the same memory location [0] (although to be fair that's from 2009; I'm not sure whether GCC still does this). For stuff like null pointer dereferences, signed overflow, or OOB dereferences, though, the compiler can (sometimes?) derive stricter bounds, which means the compiler is gleaning more information from the source code than it has previously. [0]: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...