Please use NULL instead of 0 whenever you have a pointer!

Guy Harris guy at rlgvax.UUCP
Sat Feb 4 08:50:09 AEST 1984


> After hearing all the controversy that NULL is identically equal to zero,
> the only sane solution is to fix the C language.  Add a special constant
> that is the equivalent of zero, but is a pointer.  Since NULL already has
> bad connotations, let's borrow from PASCAL, and call it NIL.

> Now NIL is guaranteed to be a pointer of the largest type (char * ?) but
> it will compare against any pointer without error and it can be passed
> as a subroutine argument.  NIL can be assigned to any pointer type, and
> will always be guaranteed to be different than a valid pointer.

> It would be nice if the definition of NIL included the restriction that
> a dereference of NIL would always cause a run-time error, but maybe this
> is too much to ask for.

> Those of us without the "fixed" compiler can #define NIL ((char *) 0)
> and use it anyway (although some of the compilers may complain about
> "illegal pointer combination"s)

Well, #define NIL ((char *)0) will do exactly what the NIL you mention
does.  EITHER ONE will cause compilers to complain - CORRECTLY - about
illegal pointer combinations.

There is no such thing as a "generic pointer" in C.  Period.  As such, there
is no such thing as a generic null pointer in C.  Period.  It may be awkward
on non-byte-addressed machines to implement (char *) and (int *) (or
(anything else *)) so that (char *)&foo and (int *)&foo yield the same bit
pattern.  Furthermore, it is not necessary, as a correct C implementation will
generate code to do the pointer format conversion if one assigns an (int *)
to a (char *), or vice versa - with ONE exception: since there is no way
to tell a C module that a function in another C module ("module" here means
"source file") takes arguments of a certain type, no C compiler can generate
code to do conversion of arguments to functions automatically.  You have to
help the compiler here by putting in explicit casts.

I read a lot of articles on this subject whose real point seems to be that
it's too much trouble to properly cast 0 or NULL when passed as an argument
to a function.  What's so hard about it?  Those of us who've worked on machines
with 16-bit "int"s and 32-bit pointers do it as a matter of habit.  I even
did it *before* I worked on such a machine, just because the minimal extra
effort to write type-correct code (yes, you *can* write code which is 99%
type-correct in C) is worth the effort.  The only thing C "needs" is a way
to declare the types of the arguments to a function, so that the compiler
can generate the casts instead of requiring the user to do so.  However,
one can put in the proper casts explicitly, so C *isn't broken* in this
regard.  People may be too lazy to use C properly, but there is a rather
low limit on the degree to which things should - or even can - be designed so
that people who don't know how to use them won't break them.

Please, people, if you don't yet know that there aren't generic pointers in
C, and therefore that there is no such thing as a generic "null pointer" in C,
and furthermore that there *shouldn't* be such a beast, please go back and
read the C Reference Manual - especially the sections I referred to in an
earlier article.  It's been explained several times here why C doesn't need
to be changed to "fix" the problem with NULL pointers; please don't force it
to be explained again.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy



More information about the Comp.unix.wizards mailing list