What if the compiler is able to use that to determine that a whole code path is dead, and then significantly improve the surrounding function because of that?
Compilers optimise in multiple passes and removing things earlier can expose optimisation opportunities later that can affect other parts of the code too
You don’t want warnings for every piece of code in a library you’re not using or sanity check you added that isn’t supposed to be hit
And you can’t warn when you’re optimising based on undefined behaviour because you can’t know when it will happen, that is equivalent to the halting problem
If you warned whenever undefined behaviour could be happening then e.g. every single pointer deference would say “warning: compiling assuming pointer is not null or unaligned”
> I don’t mean this in a rude way but you should really read the posts I linked, it’s interesting and part 3 especially answers these questions
I have read the entire series. Both in the past and more recently.
> If you warned whenever undefined behaviour could be happening then e.g. every single pointer deference would say “warning: compiling assuming pointer is not null or unaligned”
I am not proposing that at all, I am proposing (which the series you link to does not preclude) that eliding code on the basis of UB can be determined by the compiler. If the compiler can determine that some code block needs to be elided, then the reason for that elision has already been determined, in which case it can issue a warning when "reason" == "pointer already used" when eliding the null check.
When your code can be completely reshaped by earlier passes and macro expansions and inlining I don’t think it’s feasibly to make a useful warning for that
If you include a library function with a null check that gets inlined you probably don’t want a bunch of warnings there for code you don’t even control
Right. But to take the first example, the value of initialised memory.
It's undefined so it doesn't have to be zeroed therefore increasing efficiency.
But it's also UB so if you do know that memory contains something, you can't take advantage of that because it's UB. Having it UB is fine. It's the compilers assuming UB can't happen and optimising it away.
A few of those are significant performance gains, the majority are not.
Emitting the instruction for a NULL pointer dereference is effectively no more costly than not emitting that instruction.
It's the code removal that's killing me.