linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: "David D. Hagood" <wowbagger@sktc.net>, <hzhong@cisco.com>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Style question: Should one check for NULL pointers?
Date: Fri, 11 Jul 2003 11:39:51 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0307111127140.22455-100000@netrider.rowland.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0307111039400.2708@chaos>

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


  reply	other threads:[~2003-07-11 15:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-10 20:28 Style question: Should one check for NULL pointers? Alan Stern
2003-07-10 20:52 ` Eli Carter
2003-07-10 22:12   ` H. Peter Anvin
2003-07-11  2:35   ` Alan Stern
2003-07-11 14:29     ` Eli Carter
2003-07-11 15:16       ` Alan Stern
2003-07-12 18:40         ` Horst von Brand
2003-07-13 21:42           ` Alan Stern
2003-07-11 20:33       ` H. Peter Anvin
2003-07-10 22:54 ` David D. Hagood
2003-07-11  4:02   ` Hollis Blanchard
2003-07-11  4:38   ` Hua Zhong
2003-07-11 14:13     ` David D. Hagood
2003-07-11 14:52       ` Richard B. Johnson
2003-07-11 15:39         ` Alan Stern [this message]
2003-07-11 19:32 ` Horst von Brand
2003-07-11 20:36   ` H. Peter Anvin
2003-07-11 21:21   ` Alan Stern
2003-07-13 22:53 ` Ingo Oeser
     [not found] <7QmZ.5RP.17@gated-at.bofh.it>
2003-07-10 21:00 ` Dennis Bliefernicht
2003-07-10 22:13   ` H. Peter Anvin
2003-07-10 22:28     ` Larry McVoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.0307111127140.22455-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=hzhong@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=wowbagger@sktc.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).