At the system level (not the abstract virtual machine in the current specification) it is reliably known whether a null pointer dereference will return a specif

At the system level (not the abstract virtual machine in the current specification) it is reliably known whether a null pointer dereference will return a specified value (such as zeroes), unspecified values (semi-random data), or a result in a system exception (segfault) of some sort. The compiler must produce code that does that because it cannot determine whether a pointer is null in advance in most cases. So letting it do something different when it knows that a pointer is null (due to some sort of coding mistake) vs. when it doesn't know that the pointer is null is gratuitously non-deterministic behavior. The safe (if somewhat slower) thing to do is to emit the same code regardless, so that a null pointer dereference has the same effect even when inadvertently inserted into the program. The same operation should produce the same result in the same program, as much as possible anyway, and if not the same result then a similar one. It is not a reasonable assumption that any real world program will never dereference a null pointer. It is helpful that the consequence of doing so be as stable and predictable as the underlying architecture provides for.