From owner-freebsd-hackers Fri Feb 14 15:22:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10137 for hackers-outgoing; Fri, 14 Feb 1997 15:22:53 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10097 for ; Fri, 14 Feb 1997 15:22:45 -0800 (PST) Received: from nemeton.UUCP (Unemeton@localhost) by perki0.connect.com.au with UUCP id KAA28150 (8.7.6h/IDA-1.6); Sat, 15 Feb 1997 10:18:39 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id KAA12738; Sat, 15 Feb 1997 10:17:23 +1100 (EST) Message-Id: <199702142317.KAA12738@nemeton.com.au> To: Eivind Eklund cc: hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) In-reply-to: <3.0.32.19970214173652.00c0b290@dimaga.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <12731.855962183.0@nemeton.com.au> Date: Sat, 15 Feb 1997 10:17:23 +1100 From: Giles Lean Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12731.855962183.1@nemeton.com.au> On Fri, 14 Feb 1997 17:36:53 +0100 Eivind Eklund wrote: > I hereby propose changing the default declaration of NULL under FreeBSD from > #define NULL 0 > to > #define NULL ((void*)0) This is more of a kludge than a good idea, and I offer the following sage advice that I filed away many years ago. Regards, Giles ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 >From rsalz@bbn.com Tue Nov 7 09:35:09 1989 Relay-Version: version Notes 2.8.2 87/11/24; site hpausla.aso.hp.com From: rsalz@bbn.com (Rich Salz) Date: Mon, 6 Nov 1989 22:35:09 GMT Date-Received: Tue, 7 Nov 1989 13:37:34 GMT Subject: Re: NULL Message-ID: <2144@prune.bbn.com> Organization: BBN Systems and Technologies Corporation Path: hpausla!hpcuhc!hpda!hplabs!hp-sdd!ucsdhub!sdcsvax!network.ucsd.edu!ucsd!tut.cis.ohio-state.edu!ukma!mailrus!bbn!bbn.com!rsalz Newsgroups: comp.os.minix References: <4455@ast.cs.vu.nl> Lines: 99 (This is part two of the set-up. Andy and I have exchanged email about this.) I believe that if you have anything other than "#define NULL 0" you are encouraging sloppy non-portable code. Yes, casting 0 all the time is a pain, but c'est la vie. Function prototypes help. When it comes to this topic, Chris Torek is one of the many people who are smarter than I am who are also better writers. I'll let his old words try to convince people: >From bbn.com!bbn!mit-eddie!ll-xn!ames!umd5!mimsy!chris Thu Mar 10 15:37:10 EST 1988 Article 5474 of comp.lang.c: Path: bbn.com!bbn!mit-eddie!ll-xn!ames!umd5!mimsy!chris >From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Why NULL is 0 Summary: you have seen this before, but this one is for reference Message-ID: <10576@mimsy.UUCP> Date: 9 Mar 88 02:26:10 GMT References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <10574@mimsy.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 73 (You may wish to save this, keeping it handy to show to anyone who claims `#define NULL 0 is wrong, it should be #define NULL '. I intend to do so, at any rate.) Let us begin by postulating the existence of a machine and a compiler for that machine. This machine, which I will call a `Prime', or sometimes `PR1ME', for obscure reasons such as the fact that it exists, has two kinds of pointers. `Character pointers', or objects of type (char *), are 48 bits wide. All other pointers, such as (int *) and (double *), are 32 bits wide. Now suppose we have the following C code: main() { f1(NULL); /* wrong */ f2(NULL); /* wrong */ exit(0); } f1(cp) char *cp; { if (cp != NULL) *cp = 'a'; } f2(dp) double *dp; { if (dp != NULL) *dp = 2.2; } There are two lines marked `wrong'. Now suppose we were to define NULL as 0. Clearly both calls are then wrong: both pass `(int)0', when the first should be a 48 bit (char *) nil pointer and the second a 32 bit (double *) nil pointer. Someone claims we can fix that by defining NULL as (char *)0. Suppose we do. Then the first call is correct, but the second now passes a 48 bit (char *) nil pointer instead of a 32 bit (double *) nil pointer. So much for that solution. Ah, I hear another. We should define NULL as (void *)0. Suppose we do. Then at least one call is not correct, because one should pass a 32 bit value and one a 48 bit value. If (void *) is 48 bits, the second is wrong; if it is 32 bits, the first is wrong. Obviously there is no solution. Or is there? Suppose we change the calls themselves, rather than the definition of NULL: main() { f1((char *)0); f2((double *)0); exit(0); } Now both calls are correct, because the first passes a 48 bit (char *) nil pointer, and the second a 32 bit (double *) nil pointer. And if we define NULL with #define NULL 0 we can then replace the two `0's with `NULL's: main() { f1((char *)NULL); f2((double *)NULL); exit(0); } The preprocessor changes both NULLs to 0s, and the code remains correct. On a machine such as the hypothetical `Prime', there is no single definition of NULL that will make uncasted, un-prototyped arguments correct in all cases. The C language provides a reasonable means of making the arguments correct, but it is not via `#define'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out. ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 >From henry@utzoo.uucp Wed Nov 8 05:35:40 1989 Relay-Version: version Notes 2.8.2 87/11/24; site hpausla.aso.hp.com From: henry@utzoo.uucp (Henry Spencer) Date: Tue, 7 Nov 1989 18:35:40 GMT Date-Received: Thu, 9 Nov 1989 06:24:45 GMT Subject: Re: NULL Message-ID: <1989Nov7.183540.2486@utzoo.uucp> Organization: U of Toronto Zoology Path: hpausla!hpcuhc!hpda!motcsd!apple!usc!cs.utexas.edu!wuarchive!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!henry Newsgroups: comp.os.minix References: <4455@ast.cs.vu.nl> <2144@prune.bbn.com> Lines: 30 In article <2144@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: >I believe that if you have anything other than "#define NULL 0" you >are encouraging sloppy non-portable code... Unfortunately, there is a lot of sloppy non-portable code out there already, and it is desirable to minimize code breakage where possible. This is why ANSI C allows NULL to be any integer constant expression equal to zero (e.g. `0' or `0L') or the same cast to `void *' (e.g. `((void *)0)': so that you can pick one that is the same size as the pointers on your machine, to minimize breakage of badly-written code. (The rationale for allowing the `void *' cast is that there may not be an integer type the same size as the pointers.) Of course, if different pointers are different sizes, or the representation of null pointers is strange, you are well and truly up the creek and there is *no* definition that will avoid breakage. Note that casting the zero to any *other* pointer type is illegal and pointless. (Although all manner of fudging may be necessary in the presence of non-ANSI compilers.) In any case, this stuff is a concession to badly-written code. No properly-written code under ANSI compilers will notice the difference between the different forms of NULL. In contexts where the desired type is not known from context -- basically, function arguments in the absence of a prototype or the presence of varargs -- NULL *must* be cast to the proper pointer type. Lazy programmers keep looking for a way around this, but there simply *isn't any*. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu ------- =_aaaaaaaaaa0--