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

Alan Stern
2003-07-11T21:07:43Z

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