"Reading from an invalid pointer either traps or produces an unspecified value."
That still leaves room for obscure behavior:
if( p[i] == 0) { foo();}
if( p[i] != 0) { bar();}
Calling foo might change the memory p points at (p might point into the stack or it might point to memory in which foo() temporarily allocates stuff, or the runtime might choose to run parts of free() asynchronously in a separate thread), so one might see cases where both foo and bar get called. And yes, optimization passes in the compiler might or might not remove this problem.
Apart from truly performance-killing runtime checks i do not see a way to fix this issue. That probably is the reason it isn't in the list.
(Feel free to replace p[i] by a pointer dereference. I did not do that above because I fear HN might set stuff in italics instead of showing asterisks)
Short of languages like clojure and haskell that are heavily opinionated on immutability and side effects, I can't think of any languages that meaningfully protects against that kind of obscure behaviour. Indeed, it seems "else" was meant for exactly this kind of code.
That still leaves room for obscure behavior:
Calling foo might change the memory p points at (p might point into the stack or it might point to memory in which foo() temporarily allocates stuff, or the runtime might choose to run parts of free() asynchronously in a separate thread), so one might see cases where both foo and bar get called. And yes, optimization passes in the compiler might or might not remove this problem.Apart from truly performance-killing runtime checks i do not see a way to fix this issue. That probably is the reason it isn't in the list.
(Feel free to replace p[i] by a pointer dereference. I did not do that above because I fear HN might set stuff in italics instead of showing asterisks)