From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 09:36:10 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 E166A16A4CE for ; Sat, 29 Nov 2003 09:36:10 -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 B237143FBD for ; Sat, 29 Nov 2003 09:36:09 -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 hATHa9EG012577; Sat, 29 Nov 2003 09:36:09 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hATHa9Wx040657; Sat, 29 Nov 2003 09:36:09 -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 hATHa8GQ040656; Sat, 29 Nov 2003 09:36:08 -0800 (PST) (envelope-from marcel) Date: Sat, 29 Nov 2003 09:36:08 -0800 From: Marcel Moolenaar To: Bruce Evans Message-ID: <20031129173608.GA40606@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> <20031129055619.GA48381@dhcp01.pn.xcllnt.net> <20031130003519.M1415@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031130003519.M1415@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org Subject: Re: 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 17:36:11 -0000 On Sun, Nov 30, 2003 at 12:40:41AM +1100, Bruce Evans wrote: > > > > The bogusness doesn't increase if we're looking at widths. It actually > > reduces. The FreeBSD runtime is either ILP32 or LP64. Hence, defining > > NULL as long is better than defining it as int. For those running > > IP32L64, NULL can trivially be redefined as int. > > It could be MD in all cases to hide bugs in a MD way. Yes. This corresponds to MD behaviour of gcc. On alpha, amd64 and sparc64 gcc widens NULL to 64 bit for arguments that have to be passed on the stack (still in the context of variadic functions). On ia64 gcc does not do that. The end result is that the use of NULL (when defined as 0) without cast works for the first 8 arguments, because those are passed in registers, but fail for all subsequent arguments. The widening on the other platforms already hide bugs, but at least create consistent behaviour. On ia64 the behaviour is inconsistent, but AFAICT correct from a standards point of view. Nonetheless utterly bogus behaviour from usability and portability points of view. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net