Similarly, 'dead code paths' should also result in a Warning, if not an Error. (Possibly with a way of turning that off for specific functions.)
I also fully agree with the author's statement about what a good compiler should be doing.
I often write code that won't divide by zero, something I can prove because I know my whole program while the compiler only knows the file/library it is working with at the moment. As such I didn't put in a if divisor is zero check, and now want the compiler to waste my time on a warning that is wrong.
How would you implement this? For example, use-after-free is undefined, and difficult to detect.
Would it be better to only ever use unsigned integers for indvars and loop limits? Maybe. But that would reach deep into the types in stdlib for example.
And then there's https://software.intel.com/en-us/forums/intel-c-compiler/top...
So, all in all, not simple. Not that that invalidates your point: I just wanted to add some nuance.
The point of these "use UB to optimize" approaches isn't to screw over simple programs with bugs. It's to better optimize larger, correct programs where higher levels of logic that the compiler is unaware of ensure UB never happens.
Additionally, SPARC ADI, ARM MTE and CHERRY can be used to invalidate memory regions after free and trap on further accesses.
While not perfect, better than nothing.
Beyond trivial cases, UB is a runtime behaviour, not compile time.
> 'dead code paths' should also result in a Warning, if not an Error.
the noise generated would be unbearable.