Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: references to dereferenced null pointers
Message-ID: <16193@haddock.ima.isc.com>
Date: 16 Mar 90 00:59:48 GMT
References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> <12347@smoke.BRL.MIL>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 29

In article <12347@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>	#define NULL ((void*)(1-1))
>	#define NULL 0L
>	#define NULL ((void*)0)
>	#define NULL 0
>[All of the above are legal, though] the first example is silly.  I
>personally recommend the last example, which (despite some arguments you will
>get from certain IBM PC implementors) is always a correct way to define NULL
>and is simpler than the others.  However, the next-to-last example does have
>one advantage, namely that it will cause diagnostics to be generated for more
>instances of abuse of the NULL macro than will the last example.

Another idea I've been toying with is
	#define NULL __builtin_NULL
where __builtin_NULL is a keyword that, in a pointer context, acts like a
properly-typed null pointer constant (i.e. just like `0' does), and in a non-
pointer context, causes a diagnostic to be issued.  This is "even better" than
the ((void *)0) definition since it should catch *all* abuses of the macro,
though it does of course depend on having a hook in the compiler.

Strictly speaking, NULL is supposed to be defined as 0 or a casted 0, but I
think this would be legal by the as-if rule.  (Since no correct program could
tell the difference.)

(It is perhaps worth mentioning again that none of this has anything to do
with the internal representation of a null pointer, which may or may not have
all bits zero.)

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint