From owner-freebsd-current@FreeBSD.ORG Mon Mar 1 06:21:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4C5F16A4CE for ; Mon, 1 Mar 2004 06:21:50 -0800 (PST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 9131E43D31 for ; Mon, 1 Mar 2004 06:21:47 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 59466 invoked by uid 1001); 1 Mar 2004 14:21:45 -0000 Date: Mon, 1 Mar 2004 15:21:45 +0100 From: Erik Trulsson To: Thomas David Rivers Message-ID: <20040301142145.GA59401@falcon.midgard.homeip.net> Mail-Followup-To: Thomas David Rivers , current@freebsd.org, mark@grondar.org References: <200402291546.i1TFkZ0w070591@grimreaper.grondar.org> <200403011315.i21DFvC95798@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403011315.i21DFvC95798@lakes.dignus.com> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: mark@grondar.org Subject: Re: NULL vs 0 vs 0L bikeshed time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 14:21:50 -0000 On Mon, Mar 01, 2004 at 08:15:57AM -0500, Thomas David Rivers wrote: > > > > 1) Please restrain the need to bikeshed this one to death. I am > > sympathetic to technical arguments, but compulsive noise over > > such issues is annoying. > > > > 2) Please separate style disussion from technical discussion. > > > > I'd like to commit the following patch. It makes sure that for C > > and the kernel, NULL is a ((void *)0), and for C++, NULL is either > > (0L) or 0, with __LP64__ used to define the difference. > > > > The intent is to catch use of NULL where 0 or (0L) should be used. > > It generates extra warnings (I promise to fix these). > > > > I believe that _may_ be backwards; the C and C++ standards > speak to this, and both of them have slightly different > requirements. > > The C standard discuss the NULL constant, implying it is simply > a zero (not necessarily cast to a pointer.) > > But - I believe (and I need to check on this) that the C++ > standard requires the NULL constant to be a pointer type (so > various conversions work.) It's the other way around. In C NULL may be defined as an integer constant with value 0, or such a constant cast to (void*). In C++ it must be an integer constant. (The reason is that C++ has stricter type-checking and does *not* perform the implict conversions between void-pointers and other pointers that C does.) The patch seems to be technically correct and standards-compliant, and no correct programs should have any problems with the patch. However even as it will expose bugs in some programs, the patch will hide bugs in other programs. Such buggy programs caused a long thread earlier on how NULL should be defined which I suspect influenced the creation of this patch. The problem is that when using an unadorned NULL as an argument to a vararg function (or a non-prototyped function) there will be no automatic casting to the correct type. This means that if NULL is defined as 0, it will be passed as an integer even if the called function expects a (void*). For this reason correct programs must always cast a NULL to the correct type for such functions. (For functions with a prototype in scope, the argument will be automatically cast to the correct type.) This will cause problems if you have 64-bit pointers and 32-bit int's. This patch will make such programs work as intended and thus hide that this bug exists, thereby making it less likely that such programs are actually fixed. However, as indicated above, the patch will help flush out other bugs and as such it might be a good idea to use it. >From a stylistic point of view I think it is really ugly to have NULL defined in defined in different ways depending on language/architecture, but I guess that is a necessary evil if one is to find as many bugs as possible. On a related note, is there some particular reason for having the C++ definition depend on __LP64__ or could one not just as well define NULL as (0L) all the time there? (I.e. is there any platform FreeBSD runs on that have 32-bit longs and 64-bit pointers, or does all of them have pointers and long being the same size?) -- Erik Trulsson ertr1013@student.uu.se