From owner-freebsd-hackers Fri Feb 14 14:57:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07953 for hackers-outgoing; Fri, 14 Feb 1997 14:57:25 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07946 for ; Fri, 14 Feb 1997 14:57:21 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id XAA17033; Fri, 14 Feb 1997 23:55:55 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id XAA18696; Fri, 14 Feb 1997 23:46:20 +0100 (MET) Message-Id: <3.0.32.19970214234620.00b72540@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 23:46:22 +0100 To: "Arne H. Juul" From: Eivind Eklund Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:29 PM 2/14/97 +0100, Arne H. Juul wrote: >[Eivind Eklund] >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) >> for better type-safety and ease of transition to other architechtures >> (e.g. Alpha). This will probably save us from a quite a few varargs-voes, >> as well as generally making sure the code-base is using NULL correctly, >> which is important for those reading source-code. > >This *shouldn't* help. If it does, the code is broken. >All code should do the right thing with varargs; if having NULL be >plain 0 breaks it, so much the better :-) Broken code should be >found and fixed, not nurtured. We presently cannot find it; and finding it all on the Alpha port could be pretty ugly. Besides, changing it to ((void*)0) will find as much broken code as we can, fix that, and make the other closer to harmless. (It will break only on architectures where different pointers have different internal structure, which are becoming rare.) I still say we should go for it. >Ideally one should define NULL to plain 0 sometimes, to >(void *)0 sometimes, and to (1-1) (or some other bizarre but >legal option) sometimes, just to find bugs in the source tree. Would be nice if there are some legal but bizarre options - unfortuneatly, there isn't ((1-1) is illegal - integer type). The following two (with possibly added parantheses) are all there is: #define NULL 0 #define NULL ((void*)0) If I remember correctly, NULL should reduce to a single token - then stripping parantheses from the second expression is technically incorrect. (This might be an inconsistency in the standard - it does not seem to be possible to produce a statement that give an error without parantheses but work with. However, the grammar conflict will come at different points.) Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org