From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 16:58:26 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0DF16A4CE for ; Fri, 28 Nov 2003 16:58:26 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A90AC43F85 for ; Fri, 28 Nov 2003 16:58:24 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hAT0wOEG058581 for ; Fri, 28 Nov 2003 16:58:24 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id hAT0wNWx020166 for ; Fri, 28 Nov 2003 16:58:23 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hAT0wNU7020165 for standards@FreeBSD.org; Fri, 28 Nov 2003 16:58:23 -0800 (PST) (envelope-from marcel) Date: Fri, 28 Nov 2003 16:58:23 -0800 From: Marcel Moolenaar To: standards@FreeBSD.org Message-ID: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: 64-bit NULL: a followup X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2003 00:58:26 -0000 Previously on -standards: On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > a question came up wether the NULL should be defined as (0L) on sparc. > (Solaris does this). Currently we define NULL as 0. On Mon, 27 Oct 2003, Erik Trulsson wrote: > > Both are perfectly good definitions of NULL. On Mon, 27 Oct 2003, Tony Finch wrote: > > No, NULL is an implementation-defined null pointer constant, not a null > pointer. The difference is that a null pointer constant is an integer > constant expression that evaluates to zero (optionally cast to void*), > and a null pointer is a null pointer constant converted to a pointer type > (which might involve changes in representation). Therefore using a bare > NULL to terminate the execl argument list is not in general legal. On ia64 I run into a problem where a caller of a function with a variable number of arguments leaves garbage in the high order 32 bits due to the fact that NULL is defined as 0, and thus has type int by default. Take the following simple example: extern int va(int, ...); int foo(void) { return (va(1, 2, 3, 4, 5, 6, 7, 8, NULL)); } The last argument has to be passed onto the stack, which gcc does as follows: : 1c: 01 61 00 84 adds r14=16,r12;; 20: 00 00 00 1c 90 11 [MII] st4 [r14]=r0 26: 40 0a 00 00 48 a0 mov r36=1 2c: 24 00 00 90 mov r37=2 30: 00 30 0d 00 00 24 [MII] mov r38=3 36: 70 22 00 00 48 00 mov r39=4 3c: 55 00 00 90 mov r40=5 40: 00 48 19 00 00 24 [MII] mov r41=6 46: a0 3a 00 00 48 60 mov r42=7 4c: 85 00 00 90 mov r43=8 50: 1c 00 00 00 01 00 [MFB] nop.m 0x0 56: 00 00 00 02 00 00 nop.f 0x0 5c: 08 00 00 50 br.call.sptk.many b0=50 : Notice the "st4". If NULL was defined as 0L, this would look like: : 1c: 01 61 00 84 adds r14=16,r12;; 20: 00 00 00 1c 98 11 [MII] st8 [r14]=r0 26: 40 0a 00 00 48 a0 mov r36=1 : Notice the "st8". Since NULL is a pointer constant, programmers do (implicitly) expect it to have the same width as a pointer type and thus do not cast it to a pointer type or an integer type that has a width larger or equal to a pointer type. So, the bottomline is that we currently do have third-party code that fails to run on ia64 (and possibly other 64-bit platforms) due to the fact that NULL is defined as 0. Since Erik thinks 0 and 0L are both perfectly good definitions for NULL and Tony emphasizes that NULL is an integer expression, I think we should change the definition of NULL to 0L to improve portability to FreeBSD/LP64. It will definitely fix known breakages on ia64. Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net