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

Alan Stern (stern@rowland.harvard.edu)
Fri, 11 Jul 2003 11:39:51 -0400 (EDT)


On Fri, 11 Jul 2003, Richard B. Johnson wrote:

> On Fri, 11 Jul 2003, David D. Hagood wrote:
>
> > But consider the following code:
> >
> > sscanf(0,0);
> >
> > That IS an error condition - both the string to scan and the format
> > string are NULL. In this case sscanf should return EITHER 0 (no items
> > matched) or better still -1 (error).
> >
>
> But it does neither. Instead, it seg-faults your code!
>
> The problem lies with the original question. The question
> referred to "Style" (look at the subject-line). It is
> not a question about style, but a question about utility
> and design. Style has nothing to do with it.

This isn't really an example of the sort of thing I was asking about. I
was referring specifically to kernel code, not general-purpose userspace C
library routines like sscanf.

But maybe you mean the kernel's internal implementation of sscanf. If
someone in the kernel did write "sscanf(0,0);" then that would definitely
be an error in the source. It should be brought to the author's attention
as soon as possible, and a segfault (or BUG_ON) is a much more effective
way of doing so than simply returning -1.

> If you are writing code for an embedded system, the code
> must always run even if RAM got trashed from alpha particles
> or EMP. In that case, you trap every possible condition and
> force a restart off a hardware timer, refreshing everything in
> RAM from PROM or NVRAM.

Okay, but there's no way at the source level to protect against all kinds
of events like alpha particles changing a stored value. And what's the
point in checking just _some_ of them in the source if you're going to
have to check _all_ of them at a lower (hardware) level anyway?

> If you are writing code to examine the contents of sys_errlist[],
> prior to adding another error-code, then you don't check anything
> and it's file-name is probably a.out, compiled from xxx.c.

I don't understand that comment.

> So, the extent to which one checks for exceptions and provides
> utility for handling exceptions depends upon the code design, not
> it's style.

But the kernel already provides a utility for handling exceptions and has
a fairly fixed design. The extent to which one writes exception checks of
dubious value is indeed a stylistic issue, at least in this one setting.

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/