From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 27 06:29:45 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F0916A4B3 for ; Mon, 27 Oct 2003 06:29:45 -0800 (PST) Received: from falcon.midgard.homeip.net (h76n3fls24o1048.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 2749B43FBF for ; Mon, 27 Oct 2003 06:29:43 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 98737 invoked by uid 1001); 27 Oct 2003 14:29:40 -0000 Date: Mon, 27 Oct 2003 15:29:40 +0100 From: Erik Trulsson To: Harti Brandt Message-ID: <20031027142940.GA85871@falcon.midgard.homeip.net> Mail-Followup-To: Harti Brandt , sparc64@freebsd.org, standards@freebsd.org References: <20031027144140.V63585@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031027144140.V63585@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: 64bit NULL? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 14:29:46 -0000 On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > Hi all, > > a question came up wether the NULL should be defined as (0L) on sparc. > (Solaris does this). Currently we define NULL as 0. This may cause Both are perfectly good definitions of NULL. All correct programs must be able to handle either definition as well as being able to handle NULL being defined as ((void*)0) which is also a correct and fairly popular way of defining NULL (although it is not a valid definition in C++.) > problems for function with variable argument lists that expect a > terminating NULL pointer. A prominent example is execl(). Although POSIX Only for buggy invocations of such functions. > (and our man page) gives the synopsis > > execl(...., (char *)0) Looks correct. > > our man pages says that the list must be terminated by a NULL pointer, > POSIX speaks 'null pointer'. Correct. > According to ISO-C NULL is a symbol that > defines a null pointer so that: Wrong. ISO C defines NULL as 'null pointer constant'. This is not the same thing as a null pointer. >From n869.txt (a draft version of the C99 standard) 6.3.2.3 Pointers .... [#3] An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.48) If a null pointer constant is | converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. .... 48)The macro NULL is defined in as a null pointer constant; see 7.17. > > execl(..., NULL) > > appears to be legal, yet will probably cause failure on FreeBSD-sparc64. But is is not legal. If you pass NULL as an argument to a function with variable arguments, or to a function that does not have a prototype in scope (in neither case does the compiler know what type the argument should have, so it won't convert it for you) you must convert NULL to the correct pointer type. > Shouldn't we change our NULL definition to > > #define NULL (0L) No good reason to. > > ? What would break by this change? It would hide some bugs in programs that (incorrectly) assume that NULL can be used in any place that a null pointer is needed. Hiding bugs is rarely a good thing, since the bugs are less likely to be fixed then. It would of course also break the same buggy programs if used on a system where long does not have the same size or representation as a pointer. -- Erik Trulsson ertr1013@student.uu.se