Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site steinmetz.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!whuxlm!akgua!mcnc!ncsu!uvacs!edison!steinmetz!davidsen
From: davidsen@steinmetz.UUCP (Davidsen)
Newsgroups: net.lang.c
Subject: NULL pointer
Message-ID: <325@steinmetz.UUCP>
Date: Fri, 15-Nov-85 10:26:41 EST
Article-I.D.: steinmet.325
Posted: Fri Nov 15 10:26:41 1985
Date-Received: Mon, 18-Nov-85 07:09:37 EST
References: <2098@brl-tgr.ARPA> <916@celtics.UUCP> <2910@sun.uucp> <52@hadron.UUCP> <2982@sun.uucp>
Reply-To: davidsen@kbsvax.UUCP (Davidsen)
Organization: GE CRD, Schenectady, NY
Lines: 29


I expressed the following opinion at some of the early meetings of X3J11, I'll
repeat it here:

NULL being an arithmetic value rather than a pointer results in conversion
problems, special cases, etc in many cases. This can result in "portable"
programs failing on some machines, particularly those which on which all
pointers are not the same (either size or form) such as Honeywell, Buroughs,
and Cray (at least the Cray2).

Many of these problems would not exist today if the original definition of
NULL had been:

	#define NULL	((char *) 0)

rather than arithmetic zero. This would make it work on machines which use a
non-zero null pointer. I have tried doing this in a number of programs to
examine the effect on lint and/or the generated code, and have yet to find a
case where it caused a problem (although it did reveal a few genuine bugs in
"working code").

Perhaps there are cases in which this construct would cause a problem, and I
would like to hear any technical comments, particularly to those still on
X3J11 and/or early UNIX implementors.
-- 
	billD	(..seismo!rochester!steinmetz!crdos1!davidsen)
		(davidsen@GE-CRD.ARPA)

"It seemed like a good idea at the time..."