Xref: utzoo comp.lang.c++:6954 comp.std.c:2667
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c++,comp.std.c
Subject: Re: references to dereferenced null pointers
Message-ID: <16270@haddock.ima.isc.com>
Date: 23 Mar 90 21:59:52 GMT
References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> <ROBERTO.90Mar16130444@ecx1.ssd.csd.harris.com> <1990Mar23.072132.7307@athena.mit.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 15

In article <1990Mar23.072132.7307@athena.mit.edu> Ken Raeburn <Raeburn@MIT.EDU> writes:
>Could not "(void *) 0xc0000000" be used for [the macro] NULL?

Oh, I suppose you *could* (by the as-if rule)--but the compiler still has to
generate the right answer for "0" and "(void *)0", so now you've got one more
"magic string" to worry about%.  If you're going to do that, you might as well
have it expand into "__builtin_NULL", which also allows compile-time detection
of improper NULL usage&.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
________
% Also, people who understand that "0" is *always* a valid definition for
  "NULL" will suspect that you don't know what you're doing.
& E.g. wrongly using NULL instead of '\0', or passing an uncasted NULL as a
  function argument not covered by a prototype.