dereferencing null

[H. S. Teoh]

On Mon, Mar 05, 2012 at 03:43:15AM +0100, Adam D. Ruppe wrote:
[...]
> There's two cases where null annoys me though:
> 
> 1) if it is stored somewhere where it isn't supposed to be.
> Then, the location of the dereference doesn't help - the
> question is how it got there in the first place.

And having the compiler insert explicit null checks doesn't help here
either.


> 2) Segfaults in the middle of a web app, where running it under the
> same conditions again in the debugger is a massive pain in the butt.

I've come to the conclusion after years of fighting with making the
debugger work over the network to debug embedded apps, that fprintf is a
lot less painful than using a debugger. (Yes I heard that groan.) A
well-placed fprintf can narrow down the location of the problem
considerably. A nicely-wrapped multiprocess-safe fprintf that appends to
a debug file complete with getpid() information is even better.
Especially as a debug library optionally linked into the app. :-) The
only downside is that if your app takes a long time to build (or takes
too much effort to install) then a debugger is the better ticket.


[...]
> I've trained myself to use assert (or functions with assert in out
> contracts/invariants) a lot to counter these.

Yeah, asserts and DbC is extremely useful in detecting the problem at
its source rather than who knows how long later down the road where all
traces to the source is practically already non-existent. Thing is, you
have to consistently do this, everywhere in your code. And everyone else
on the project as well. Leave out one place, and it will just be that
very place that eventually causes problems. Murphy's law at work. :-)


T

-- 
Having a smoking section in a restaurant is like having a peeing section
in a swimming pool. -- Edward Burr