if (p), where p is a pointer - PLEASE READ
Guy Harris
guy at sun.uucp
Thu Sep 19 16:05:02 AEST 1985
> Well, now we come to the can of worms which causes some implementations to
> #define NULL (char *) 0: machines where pointers occupy more space than
> ints.
Unfortunately, #defining NULL as (char *)0 will provoke more "lint"
messages, which is not what is wanted here. If you're going to make
"typical" code work on those machines (I spent a fair bit of time doing
exactly that at CCI, along with some code - like "sdb" - which, if it's
typical, means we're all in deep trouble; but I digress) you have to run it
through "lint" to catch all the pointer-valued functions which aren't so
declared.
> Same comment as above. The solution may be that NULL should be 0L (but what
> about the venerable old PDP-11? In that case, foo(NULL) passes too much
> stuff on the stack. So, what is *the* answer?)....
In that case, you could have different definitions of NULL for different
machines. But what about a hypothetical machine (which is, I suspect, not
so hypothetical) with 64K 16-bit words in a process' address space and a
special two-word format for byte pointers? In that case, (int *)NULL would
be 16 bits but (char *)NULL would be 32 bits.
*The* answer is to cast each NULL/0 yourself, or wait for ANSI C and have it
do the coercions for you (which doesn't help with existing code).
In retrospect, perhaps C should have had a keyword like "nil" to represent
null pointers.
1) Assignments of the sort
pointer_variable = <integer_expression>;
would no longer have different meanings depending on whether the
<integer_expression> was a constant 0 or not.
2) The confusion that has sprung up between null pointers and pointers
filled with 0 bits - and the subsequent confusion indicated by people
thinking NULL should *really* be defined as a constant with the same bit
pattern as a null pointer on a particular machine - might have been avoided.
3) If the rules for "nil" were that a) a naked "nil" is illegal but b) as
the operand of an operator whose other operand or result were of a
particular pointer type, a "nil" becomes a null pointer of that type, code
like
setbuf(stdout, nil);
would be illegal (no such operator nearby) and the "nil" would have to be
properly cast. "int *p; p = nil;" would compile properly, as the "nil" is
an operand of the "=" whose other operand is a "pointer to int".
However, hindsight is 20/20; if C had everything in it that it "should" have
had, it might be a better language but its compiler might not have fit on
the PDP-11...
Guy Harris
More information about the Comp.lang.c
mailing list