Re: Style question: Should one check for NULL pointers?

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, 11 Jul 2003, Horst von Brand wrote:

> My personal paranoia when reading code goes the other way: How can I be
> sure it won´t ever be NULL?  Maybe it can't be now (and to find that out an
> hour grepping around goes by), but the very next patch introduces the
> possibility.  Better have the function do an extra check, or make sure
> somehow the assumption won't _ever_ be violated. But that is a large (huge,
> even) cost, so...

Suppose something does change and your function is passed a NULL pointer 
after all.  What will you do about it then?  Clearly this represents a 
mistake on the part of the caller; are you simply going to return without 
doing anything and hope that nothing else will go wrong?  Or will you 
return an error code and hope that a caller careless enough to pass an 
invalid argument will also be careful enough to check the return code?
Quite a lot of places in the kernel do one of these (usually the first).

Neither of those options is attractive to me.  I would prefer something 
that leaves a clear indication that the problem exists.  A logged error 
message would help; a BUG_ON or segfault would be even better.  This is 
especially true in situations where the function in question is part of a 
relatively small subsystem where you _know_ that a NULL pointer is never 
valid.  (It may occur, but if it does it must represent an error.)

Alan Stern