From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17647 invoked by alias); 5 Jul 2005 07:30:04 -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 17575 invoked by uid 22791); 5 Jul 2005 07:29:57 -0000 Received: from server7.nfra.nl (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 07:29:57 +0000 Received: from jop31.nfra.nl [10.87.10.31] by server7.nfra.nl; Tue, 05 Jul 2005 09:29:11 +0200 Received: from jop31.nfra.nl (localhost [127.0.0.1]) by jop31.nfra.nl (8.13.1/8.12.7/SuSE Linux 0.6) with ESMTP id j657SvFu005198; Tue, 5 Jul 2005 09:28:57 +0200 Received: (from kettenis@localhost) by jop31.nfra.nl (8.13.1/8.13.1/Submit) id j657SueI005195; Tue, 5 Jul 2005 09:28:56 +0200 Date: Tue, 05 Jul 2005 07:30:00 -0000 Message-Id: <200507050728.j657SueI005195@jop31.nfra.nl> From: Mark Kettenis To: eliz@gnu.org CC: gdb-patches@sourceware.org In-reply-to: (message from Eli Zaretskii on Tue, 05 Jul 2005 06:34:18 +0200) Subject: Re: [commit] Properly cast sentinels for concat() References: <200507041336.j64Da5cE001221@jop31.nfra.nl> <20050704225153.GA31424@nevyn.them.org> X-SW-Source: 2005-07/txt/msg00059.txt.bz2 Date: Tue, 05 Jul 2005 06:34:18 +0200 From: Eli Zaretskii > Date: Mon, 4 Jul 2005 18:51:53 -0400 > From: Daniel Jacobowitz > Cc: Mark Kettenis , gdb-patches@sourceware.org > > 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. But in Mark's case, NULL is defined as (void *)0, so it's a pointer, not an int. No it isn't, OpenBSD has #define NULL 0L which incidentally has the nice property that it makes GCC warn about a potential problem with the code without actually having that problem on any OpenBSD platform (which are either ILP32 or LP64). This defenition would expose the bug Daniel describes on IL32 P64 platforms (64-bit Windows, HP-UX on Itanium). > 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++. We are not talking about C++ code here, nor about a C++ compiler. Not that I think that it is a good thing, but Andrew has been talking about making GDB compilable with a C++ compiler before. Do you still want me to revert the patch? Mark