From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Mark Kettenis <kettenis@jive.nl>, gdb-patches@sourceware.org
Subject: Re: [commit] Properly cast sentinels for concat()
Date: Tue, 05 Jul 2005 01:32:00 -0000 [thread overview]
Message-ID: <20050704225153.GA31424@nevyn.them.org> (raw)
In-Reply-To: <ud5pyp3tl.fsf@gnu.org>
On Tue, Jul 05, 2005 at 01:08:22AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 4 Jul 2005 15:36:05 +0200
> > From: Mark Kettenis <kettenis@jive.nl>
> >
> > This fixes a few warnings with GCC 4.0 on OpenBSD. You'll probably
> > won't see them on other systems, since they only show up if NULL is
> > defined as an integer instead of a pointer constant (both are valid
> > according to C standard). The stddef.h that comes with GCC defines
> > NULL as (void *)NULL, but we don't use that one on OpenBSD.
> >
> > Anyway, I committed the attached patch as obvious.
>
> Actually, it's not at all obvious, it's IMNSHO simply wrong. Casting
> NULL to _anything_ should never be needed, unless NULL is abused
> (i.e. used in a place where a pointer cannot be). Let's not decide
> that a patch is ``obvious'' just because it happens to shut up the
> compiler!
You must cast NULL to a pointer type if you use it as the sentinel in a
varargs list, in portable code, because 0 is a legal definition of NULL
(according to the C standard, which is quite clear on the subject). On
an I32 LP64 system, passing 0 to a varargs function may take 32 bits on
the stack while passing NULL takes 64 bits. If you pass the wrong one,
you'll wander up the stack to nowhere.
This is often called "the execl bug", because execl is the most
frequently used function in the standard library which takes NULL as a
terminator for a list of string constants.
Even more C++ implementations use 0, which makes the problem even
worse. ISTR that (void *)0 is not an acceptable definition of NULL in
C++.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-07-05 1:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-04 13:36 Mark Kettenis
2005-07-04 22:08 ` Eli Zaretskii
2005-07-04 23:16 ` Andreas Schwab
2005-07-05 1:32 ` Daniel Jacobowitz [this message]
2005-07-05 3:34 ` Eli Zaretskii
2005-07-05 4:23 ` Daniel Jacobowitz
2005-07-05 7:30 ` Mark Kettenis
2005-07-05 20:03 ` Eli Zaretskii
2005-07-05 7:36 ` Mark Kettenis
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=20050704225153.GA31424@nevyn.them.org \
--to=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=kettenis@jive.nl \
/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