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

[H. Peter Anvin]

Followup to:  <[e-mail]>
By author:    Horst von Brand <[e-mail]>
In newsgroup: linux.dev.kernel
>
> Alan Stern <[e-mail]> said:
> 
> [...]
> 
> > Suppose everything is working correctly and the pointer never is NULL.  
> > Then it really doesn't matter whether you check or not;  the loss in code
> > speed and size is completely negligible (except maybe deep in some inner
> > loop).  But there is a loss in code clarity; when I see a check like that
> > it makes me think, "What's that doing there?  Can that pointer ever be
> > NULL, or is someone just being paranoid?"  Distractions of that sort don't
> > help when trying to read code.
> 
> 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...
> 

And you just shot yourself in the foot, majorly, because you tested
for NULLness and then took the action you anticipated might have been
appropriate, which really it wasn't, and you allowed a kernel with
now-corrupt data structures to continue to run.

This is bad.  This is extrememly bad.  And your "forward thinking"
*caused* it.

A null pointer dereference in the kernel is fatal for a reason.  It
indicates that there are interfaces that aren't consistent, and your
data structures are now completely unreliable.

	-hpa
-- 
<[e-mail]> at work, <[e-mail]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64