> The problem is that dereferencing a null pointer does not actually have undefined semantics, it has system defined semantics.
No it does not. Look in the standard.
Seriously though, I get what you mean but what is the point of having a systems-defined NULL dereference? The semantics of the NULL pointer (in C) is such that you are not meant to dereference it. If you dereference it, you have a bug no matter what the manifestation on a specific system is.
And there are probably actual systems where it would be hard to specify the behaviour. For example MMU-less systems, where you can derefence byte 0 but it might not be statically clear what kind of value is stored there?
Maybe C allows a systems-defined behaviour to be implemented as undefined behaviour? But then the distinction is kinda moot.
I think butlerm was saying that dereferencing a null pointer has system-defined semantics in machine code, and that C should inherit those semantics.
> If you dereference it, you have a bug no matter what the manifestation on a specific system is.
Sure, if you dereference a null pointer you have a bug. But all sufficiently large programs have bugs, and what happens after you trigger the bug is important. The closer the machine code matches your C code, the more likely you are to be able to diagnose the problem from its symptoms.
> Maybe C allows a systems-defined behaviour to be implemented as undefined behaviour
C standard distinguishes undefined behavior, unspecified behavior and implementation-defined behavior. The first is invalid and inconsistent, the second is valid and inconsistent, the third is valid and consistent (in scope of implementation).
It is rather hard to require invalid but consistent, as the platform itself may produce inconsistent behavior in invalid cases. So what some people want is something like - "be no more inconsistent that would be naive implementation on given platform", but that is both vague and not really useful. And while some of these undefined-based optimizations seems egregious, some are necessary in order to have reasonably performant code (e.g. keeping variable values in registers instead of propagating them from/to memory after each step).
The point of having a system-defined NULL dereference (or whatever else is UB) is predictability both at compile-time and at run-time - given a particular system and a piece of high-level code, you can infer roughly what the compiled low-level code is; this means that given a bug, since odds are good you know what system the code is running on, you probably have a leg up in understanding what went wrong.
It's nice being able to strap your program into GDB and have it breakpoint at the point of a NULL dereference because it triggered a segfault, instead of needing to magically infer why results are wrong anywhere in the program because the compiler decided to inject nasal demons due to some subtle optimization pass.
The interrupt descriptor table in real mode on x86 is stored at the zero page. It is valid to dereference a pointer with value zero under DOS. Modern OS's explicitly avoid mapping at page zero in order to trap NULL pointer dereferences.
That does not mean you cannot access memory mapped at zero, just that the system might have mechanisms to catch errant programs. It is not the responsibility of the C compiler to make the distinction of whether or not accessing memory at zero is errant, but rather the architecture and the system which determine how to respond to a process that attempts to do so.
Again, the C standard came later, and in many cases the standard is about consistency across platforms where there's plenty of useful behaviors of specific platforms that you want to take advantage of. And that the modern practice of optimizing compliers emitting nasal demons gets in the way of.
No it does not. Look in the standard.
Seriously though, I get what you mean but what is the point of having a systems-defined NULL dereference? The semantics of the NULL pointer (in C) is such that you are not meant to dereference it. If you dereference it, you have a bug no matter what the manifestation on a specific system is.
And there are probably actual systems where it would be hard to specify the behaviour. For example MMU-less systems, where you can derefence byte 0 but it might not be statically clear what kind of value is stored there?
Maybe C allows a systems-defined behaviour to be implemented as undefined behaviour? But then the distinction is kinda moot.