non-zero NULL pointers (oh nooooo!) (was: Re: retiring gets(3))

[Chris Torek]

In article <8058 at bloom-beacon.MIT.EDU> scs at athena.mit.edu (Steve Summit)
writes:
>The fact that the null pointer constant in C is "0" does not,
>repeat not, place any restrictions on the bit pattern used by the
>generated code.  Using "0," rather than some machine-dependent
>value, increases portability: the translation to the machine-
>dependent value is made by the compiler, along with all
>of the other machine-dependent translations.  (Sadly, the use of
>0 as the null pointer constant has increased programmer confusion
>more than it has decreased machine dependencies.)

Right.

One way to perhaps clear up some of the confusion is to think of it
this way:  If C had had a `nil' keyword, one would not write

	char *p = 0;

but rather

	char *p = nil;	/* almost like `var p: ^char; begin p := nil;' :-) */

Now, if we had this keyword, we could also write:

	int execl(char *prog, char *av0, ...);

and a call like

	execl("foo", nil);

would know to cast the `nil' into a `char *' (which might very well
produce the binary value `-1'), while the call

	execl("foo", "foo", nil);

could correctly complain that it has no idea what *kind* of nil
to provide.

But C does not have the `nil' keyword; instead, it has `0'.  When the
compiler sees `0', it asks whether the `0' is filling in for `nil'.  If
so, it provides the appropriate cast.  If it cannot tell, it *assumes*
that the 0 is really a 0!

The moral?  Put in the cast.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris