dereferencing null

[Jonathan M Davis]

On Monday, March 05, 2012 23:58:48 Chad J wrote:
> On 03/05/2012 11:27 PM, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
> >> There are two independent discussions being conflated here. One about
> >> getting more
> >> information out of crashes even in release mode and the other about
> >> adding runtime checks to prevent crashing merely in debug builds.
> > 
> > A segfault should _always_ terminate a program - as should dereferencing a
> > null pointer. Those are fatal errors. If we had extra checks, they would
> > have to result in NullPointerErrors, not NullPointerExceptions. It's
> > horribly broken to try and recover from dereferencing a null pointer. So,
> > the question then becomes whether adding the checks and getting an Error
> > thrown is worth doing as opposed to simply detecting it and printing out
> > a stack trace. And throwing an Error is arguably _worse_, because it
> > means that you can't get a useful core dump.
> > 
> > Really, I think that checking for null when dereferencing is out of the
> > question. What we need is to detect it and print out a stacktrace. That
> > will maximize the debug information without costing performance.
> > 
> > - Jonathan M Davis
> 
> Why is it fatal?
> 
> I'd like to be able to catch these.  I tend to run into a lot of fairly
> benign sources of these, and they should be try-caught so that the user
> doesn't get the boot unnecessarily.  Unnecessary crashing can lose user
> data.  Maybe a warning message is sufficient: "hey that last thing you
> did didn't turn out so well; please don't do that again." followed by
> some automatic emailing of admins.  And the email would contain a nice
> stack trace with line numbers and stack values and... I can dream huh.
> 
> I might be convinced that things like segfaults in the /general case/
> are fatal.  It could be writing to memory outside the bounds of an array
> which is both not bounds-checked and may or may not live on the stack.
> Yuck, huh.  But this is not the same as a null-dereference:
> 
> Foo f = null;
> f.bar = 4;  // This is exception worthy, yes,
>              // but how does it affect unrelated parts of the program?

If you dereference a null pointer, there is a serious bug in your program. 
Continuing is unwise. And if it actually goes so far as to be a segfault 
(since the hardware caught it rather than the program), it is beyond a doubt 
unsafe to continue. On rare occasion, it might make sense to try and recover 
from dereferencing a null pointer, but it's like catching an AssertError. It's 
rarely a good idea. Continuing would mean trying to recover from a logic error 
in your program. Your program obviously already assumed that the variable 
wasn't null, or it would have checked for null. So from the point of view of 
your program's logic, you are by definition in an undefined state, and 
continuing will have unexpected and potentially deadly behavior.

- Jonathan M Davis