All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Style question: Should one check for NULL pointers?
Date: 10 Jul 2003 15:13:52 -0700	[thread overview]
Message-ID: <bekof0$g7i$1@cesium.transmeta.com> (raw)
In-Reply-To: 3F0DD3FD.3030403@triphoenix.de

Followup to:  <3F0DD3FD.3030403@triphoenix.de>
By author:    Dennis Bliefernicht <itsme.nospam@triphoenix.de>
In newsgroup: linux.dev.kernel
> 
> The problem is IMHO code where some pretty fragile things are handled, 
> especially file systems. I'd say: DO the paranoia checks if some fragile 
> things are involved like key structures of the file system that can take 
> _permanent_ damage. If you check for a NULL pointer you still have the 
> chance to properly leave the system in a consistent state and no user 
> will be happy if his filesystem goes messy just because someone saved a 
> check to have nicer code, even if the original of the NULL pointer 
> wasn't his fault, even if it's a developing version. So if the check 
> isn't a total performace disaster, do it whenever permanent damage could 
> occur.
> 

Actually, you have it somewhat backwards.

In most cases, checking for NULL pointers (and returning an error
whatnot) is actually *more* likely to cause permanent damage than
having the kernel bomb out.  At least with the kernel bombing out you
won't keep grinding on a filesystem for which your kernel
datastructures are bad.  This is *IMPORTANT*.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

  reply	other threads:[~2003-07-10 22:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7QmZ.5RP.17@gated-at.bofh.it>
2003-07-10 21:00 ` Style question: Should one check for NULL pointers? Dennis Bliefernicht
2003-07-10 22:13   ` H. Peter Anvin [this message]
2003-07-10 22:28     ` Larry McVoy
2003-07-10 20:28 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
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

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='bekof0$g7i$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.