Interesting read:
In other words: any language that merges null behaviour in the underlying storage will have a problem somwehere.
So if you want to have true nullable types, your null flag should be stored outside the underlying storage.
The .NET framework 2 and up, most database management systems and many other environment support that.
But most languages don’t support it for pointer types. So there will be portions of address spaces either inaccessible, or only accessible when skipping the null pointer checks.
Note that the thread above contains some very interesting bits, for instance this one:
Matt 28 Mar 2013 5:58 PM #
@MarkY “Dereferencing null is undefined? Cool! I thought it was guaranteed to crash, just like a false assertion or something. So crashing is the OS guarantee, not the language guarantee apparently.”
Nope. It’s not an OS guarantee either. The OS won’t ever normally allocate memory at address zero, but there’s nothing to stop you telling it to. Try doing “VirtualAlloc(1, 4096, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE)” on your pre-Windows8 machine.
In fact, this is the reason why null-dereferences in kernel mode are often exploitable as elevation of privilege attacks. The null-page is mappable and within the user-addressable region of memory, so if the kernel dereferences a null pointer, it reads attacker controllable data.
And btw, this is the reason why on Linux and Windows8+ you can’t map the null-page.
–jeroen
The Wiert Corner - irregular stream of stuff 