From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Style question: Should one check for NULL pointers?
Date: 11 Jul 2003 13:33:18 -0700 [thread overview]
Message-ID: <ben6ue$mj9$1@cesium.transmeta.com> (raw)
In-Reply-To: 3F0EC9C9.4090307@inet.com
Followup to: <3F0EC9C9.4090307@inet.com>
By author: Eli Carter <eli.carter@inet.com>
In newsgroup: linux.dev.kernel
> >
> > Not really needed, since a segfault will produce almost as much
> > information as a BUG_ON(). Certainly it will produce enough to let a
> > developer know that the pointer was NULL.
>
> Your first message said, "I see no reason for pure paranoia,
> particularly if it's not commented as such." A BUG_ON() call makes it
> clear that the condition should never happen. Dereferencing a NULL
> leaves the question of whether NULL is an unhandled case or invalid
> input. BUG_ON() is an explicit paranoia check, and with a bit of
> preprocessing magic, you could compile out all of those checks.
>
> So it documents invalid input conditions, allows you to eliminate the
> checks in the name of speed or your personal preference, or use them to
> help with debugging/testing.
>
... but it also bloats the code, in this case, in many ways
needlessly. You don't want to compile out all BUG_ON()'s, just the
ones that wouldn't be checked for anyway.
In fact, have a macro that explicitly tests for nullness by
dereferencing a pointer might be a good idea; on most architectures it
will be a lot cheaper than BUG_ON() (which usually requires an
explicit test), and the compiler at least has a prayer at optimizing
it out.
-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
next prev parent reply other threads:[~2003-07-11 20:21 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 [this message]
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
[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='ben6ue$mj9$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.