Messages in this thread | | | Date | Fri, 11 Jul 2003 17:21:33 -0400 (EDT) | From | Alan Stern <> | Subject | Re: Style question: Should one check for NULL pointers? |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |