Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.lang.c
Subject: Re: Abandon NULL for (0)
Summary: Let's say it again--these are broken implementations
Message-ID: <16178@vail.ICO.ISC.COM>
Date: 6 Oct 89 19:11:13 GMT
References: <15571@nswitgould.cs.uts.oz>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 28

karl_auer_%7801.801@fidogate.fido.oz writes:

> There is another good reason not to use '(0)' - in some
> implementations of C, pointers can have different sizes, requiring
> that NULL be sometimes defined as (0), sometimes as (0L) - as with
> almost all 80n86 implementations!...

We seem to have to go through this rather frequently, but:

NULL should never need to be defined as 0L.  The compiler is required to
treat 0 in a pointer assignment or comparison as a null pointer, period.
Whatever conversions or adjustments are required MUST be done transpar-
ently or the compiler is broken, period.

The one case the compiler will not handle (in pre-function-prototype C) is
calling a function with a null pointer as an actual parameter.  In this
case a cast is required--NOT a lengthening of the pointer, but a cast to
the appropriate type.  In this case it's the responsibility of the program,
and if the program doesn't do it, it's broken.

80386 C implementations don't have a problem because (unless the implemen-
tor was stupid or lazy), ints and pointers are 32 bits.  80n86, n<3, need
not have a problem.  Some implementations do, but they're broken.
-- 
+---------+     Dick Dunn    rcd@ico.isc.com    ico!rcd      (303)449-2870
| In this |         4th annual MadHatterDay [10/6/89]:
|  style  |               Madness takes its toll
|__10/6___|