dan@ttds.UUCP (Dan Sahlin) (01/13/84)
<blank line> Someone claimed that NULL was exactly the same as 0. This is however not true of you have a compiler with 16 bit integers, and 32 bit addresses. I have spent a lot of time "debugging" programs that implicitly assume that pointers and integers have the same length. Dan Sahlin (..mcvax!enea!ttds!dan)
guy@rlgvax.UUCP (Guy Harris) (01/14/84)
Actually, in <stdio.h> NULL is defined as 0, which is really as it should
be. So whether you use 0 or NULL makes no difference (unless somebody
made the mistake of defining NULL as "(char *)0"); you still have to
cast it explicitly. Then again, that's what "lint" is for; it's a good
idea to run "lint" on any program which isn't a quick throw-away or very
small and written by somebody you *know* won't make type errors - on the
other hand, I don't know anybody like that, myself included.
(If NULL were defined as "(char *)0", "lint" would get gastric distress
whenever NULL were passed as a pointer argument to a routine which expected
an "int *" or something like that. Furthermore, if you tried to assign
"(char *)0" to an "int *" variable, PCC would justifiably complain about
an illegal pointer combination. C doesn't have the notion of a generic
"null pointer", it has a "null pointer to char" which is distinct from
"null pointer to int" which is distinct from "null pointer to
(struct proc)"....)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guykvm@basservax.SUN (Karlos Mauvtaque) (01/18/84)
Dennis Ritchie says that 0 is the 'null pointer'. Read your reference manual guys. There is no place in the language where there is null pointer ambiguity. 'null pointer's as arguments to function calls must be cast to the correct pointer type whether you use NULL or 0. You can't assume that (char *) is the same size as all other pointers so #define NULL ((char *)0) won't do you any good. I use NULL rather than 0 because it's good style.
mark@cbosgd.UUCP (01/24/84)
If NULL and 0 are supposed to be the same, please explain what proper
behavior is in the following situation:
execl("/bin/echo", "echo", "hi", "there", 0);
(This is the way it's documented in exec(2) and used everywhere.)
Now, suppose you have a system where ints are 16 bits and char *'s
are 32 bits. (Hmm, sounds like a 68000.) Now, it's clear we have a
series of 32 bit values on the stack, followed by a 16 bit zero, followed
(if you keep looking) by garbage.
The only clean solution I know of (other than using 32 bit ints, which
is inefficient) is to use NULL and have NULL be (void *) 0. This is
obviously pretty painful, given all those programs out there that use
exec.
Considering that it's quite reasonable for either the high 16 bits or
the low 16 bits of a valid 32 bit pointer to be zero, is there some
other reasonable way to handle this?