Path: utzoo!attcan!uunet!decwrl!elroy.jpl.nasa.gov!jpl-devvax!jenkins
From: jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins)
Newsgroups: comp.os.minix
Subject: Re: stdio.h : NULL
Summary: #define NULL 0 okay
Message-ID: <9769@jpl-devvax.JPL.NASA.GOV>
Date: 2 Oct 90 14:50:08 GMT
References: <32108@nigel.ee.udel.edu>
Reply-To: jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 29

In article <32108@nigel.ee.udel.edu> UPSYF173%DBIUNI11.BITNET@cunyvm.cuny.edu (Wolfgang Thiel) writes:
>[...]
>         #define NULL 0
>This really is bad!! [....] Of course, my machine's pointer size is not
>sizeof int. Doesn't   #define NULL  ((void *)0)  do the job an any machine?

In C, the integer constant 0 can always be used to represent a nil
pointer.  So "#define NULL 0" is correct.  The relative sizes of
pointers and ints are irrelevant, as is the internal representation of
the nil pointer.

The constant 0 can be used uncast in any pointer context.  It's the
compiler's job to infer from the context that it's a nil pointer.
One common case where the compiler can't tell is in actual function
arguments where a prototype is not in scope.  In this case the
compiler rightfully treats 0 as an integer, and pain follows.  In
these cases you should use a prototype (if your compiler supports
them) or cast 0 to the appropriate pointer type.

(void *) 0 is allowable, but unnecessary.  It doesn't fix the general
problem;  without a prototype or cast, it will fail similarly on
machines with more than one size of pointer.

See the Frequently-Asked-Questions list in comp.lang.c for the
distillation of *years* of discussion of this problem.

-- 
Steve Jenkins N6UNI			jenkins@jpl-devvax.jpl.nasa.gov
Caltech/Jet Propulsion Laboratory	(818) 354-0162