NULL vs 0 - chapter and verse

[Charles LaBrec]

For the most part, I stand corrected.  It's amazing that when I've read
the manual before, the PRECISE meaning of NULL's escaped me.  Rereading
the sections again showed me that most of us have been wrong about NULL.
Only the *assignment* or *comparison* of 0 to a pointer produces a NULL
pointer.  A NULL pointer is *not* 0.  Therefore, I think in the future I
will not use "foo(0)" (with or w/o using NULL).  However, it might still
be argued that this is still legal C, since the manual also states that
"In preparing for the call to a function, *a copy is made of each actual
parameter*" (pg. 186, italics mine).  Sounds like an assignment, doesn't
it?

Guy however pointed out something about the 32/16 problem that does break
the standard--the fact that the subtraction of two pointers produces an
int that is the number of elements between the two pointers.  I don't see
a "portable" way of resolving this difficulty.

Since I was wrong about "NULL == 0", that part of my argument is invalid.
(By the way, I meant "NULL pointer" rather than what stdio #defines it to 
be.)  However, I stand by the spirit of paragraph--an implementation must
adhere to the letter of manual, or the implementation is flawed.  I won't
go as far to say that "it ain't C", but it does make portability a *big*
problem.

By the way, I don't necessarily consider a program that does/doesn't
pass through lint to be correct/incorrect.  While this is almost always
the case, it is still someone's interpretation of the standard (I say
"someone" rather loosely, including corrections made over the years).

Thanks, Guy, for the exact quotes.

Charles LaBrec
UUCP:		pur-ee!Physics:crl, purdue!Physics:crl
INTERNET:	crl @ pur-phy.UUCP

p.s. Does everyone consider stucture assignment and function passing and
     enums (flawed though they may be) to be part of the "official" standard?
     Has anyone heard of an updated version of the reference manual?