dereferencing null

[Jonathan M Davis]

On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
> It's not that the null pointer itself corrupts memory. It's that the
> null pointer is a sign that something may have corrupted memory *before*
> you got to that point.
> 
> The point is, it's impossible to tell whether the null pointer was
> merely the result of forgetting to initialize something, or it's a
> symptom of a far more sinister problem. The source of the problem could
> potentially be very far away, in unrelated code, and only when you tried
> to access the pointer, you discover that something is wrong.
> 
> At that point, it may very well be the case that the null pointer isn't
> just a benign uninitialized pointer, but the result of a memory
> corruption, perhaps an exploit in the process of taking over your
> application, or some internal consistency error that is in the process
> of destroying user data. Trying to continue is a bad idea, since you'd
> be letting the exploit take over, or allowing user data to get even more
> corrupted than it already is.

Also, while D does much more to protect you from stuff like memory corruption 
than C/C++ does, it's still a systems language. Stuff like that can definitely 
happen. If you're writing primarily in SafeD, then it's very much minimized, 
but it's not necessarily eliminated. All it takes is a bug in @system code 
which could corrupt memory, and voila, you have corrupted memory, and an @safe 
function could get a segfault even though it's correct code. It's likely to be 
a very rare occurrence, but it's possible. A since when you get a segfault, 
you can't know what caused it, you have to assume that it could have been 
caused by one of the nastier possibilites rather than a relatively benign one.

And since ultimately, your program should be checking for null before 
derefencing a variable in any case where it could be null, segfaulting due to 
dereferencing a null pointer is a program bug which should be caught in 
testing - like assertions in general are - rather than having the program 
attempt to recover from it. And if you do _that_, the odds of a segfault being 
due to something very nasty just go up, making it that much more of a bad idea 
to try and recover from one.

- Jonathan M Davis