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

["Hua Zhong" <hzhong@cisco.com>]

> There is an old saying in software design:
> 
> "Never check for an error condition that you do not know how 
> to handle."
> 
> In other words: if you have identified a possible error 
> condition (such as a NULL pointer), until you have identified a way to
meaningfully 
> handle that error condition, simply testing for it is useless.
> Now, if you have some function that can return an error code, then 
> testing for NULL and returning an error condition is sensible. But if 
> you have no way to report the error, then what good is the test?

Not always true. In some cases you know how to handle: just return
without doing anyting.

man 3 free

It's an example that passing a NULL is allowed by the API.
 
> However, if you test for NULL, and log a report when you 
> detect it then 
> deref it anyway (to force an OOPS, in other words throw an 
> exception), 
> then at least there is some meaningful info in the log.
> 
> But just doing something like
> 
> void foo(void *ptr)
> {
>     if (!ptr)
>       return;
> 
>     ....
> }
> 
> just masks the problem.
> 
> -
> 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/
>