From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27395 invoked by alias); 5 Jul 2005 01:32:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27385 invoked by uid 22791); 5 Jul 2005 01:32:21 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 01:32:21 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DpZn7-0008Bs-OQ; Mon, 04 Jul 2005 18:51:53 -0400 Date: Tue, 05 Jul 2005 01:32:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [commit] Properly cast sentinels for concat() Message-ID: <20050704225153.GA31424@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Mark Kettenis , gdb-patches@sourceware.org References: <200507041336.j64Da5cE001221@jop31.nfra.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00054.txt.bz2 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 > > > > 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