if (p), where p is a pointer - PLEASE READ

[Guy Harris]

> 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