Xref: utzoo comp.lang.c++:6784 comp.std.c:2590
Newsgroups: comp.lang.c++,comp.std.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: references to dereferenced null pointers
Message-ID: <1990Mar12.175613.12082@utzoo.uucp>
Organization: U of Toronto Zoology
References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <52081@microsoft.UUCP> <25F8D2FB.10981@paris.ics.uci.edu> <1990Mar11.015305.28264@utzoo.uucp> <1990Mar11.222634.2701@almira.uucp>
Date: Mon, 12 Mar 90 17:56:13 GMT

In article <1990Mar11.222634.2701@almira.uucp> haug@Columbia.NCR.COM (Brian Haug) writes:
>    I beg to differ.  I see where you are coming from with the wording:
>"an integral constant expression with the value 0", but in K&R First edition,
>page 97, there is an explicit example which 0 is returned by a function
>returning a pointer to a character...

K&R1 was kind of sloppy about this, partly because the pdp11 let you get
away with a lot.  However, the definition of C was the reference manual,
not the textbook...

>    Also, from Appendix A, section 7.7 (Equality operators) "A pointer may be
>compared to an integer, but the result is machine dependent unless the integer
>is the constant 0.  A pointer to which 0 has been assigned is guaranteed no to
>point to any object, and will appear to be equal to 0; in conventional usage,
>such a pointer is considered to be null."  This implies to me that I can
>compare a pointer to any arbitrary expression which evaluates to 0 and have
>machine independent behavior...

How do you conclude this from a statement which explicitly says that the
comparison is machine-dependent unless the *constant* 0 is used?

>And from section 7.14, "it is guaranteed that
>the assignment of the constant 0 to a pointer will produce a null pointer
>distinguishable from a pointer to any object."  Since the "BNF" for this
>section lists "lvalue = expression," I would assume that if expression
>evaluates to 0 then the pointer will produce a null pointer distinguishable
>from a pointer to any object.

Again, you're ignoring the fact that the text quite explicitly calls for
the *constant* 0 to be used.  The BNF defines only the syntax, not the
semantics and type structure; it must be read together with the text to
understand the language.

>    As far as ANSI C goes, I do not have easy access to the standard at the
>current time, nor the experience reading it.  However, I would have expected
>this behavior to be brought forward...

ANSI C carries forward the rules from K&R1 and later references:  a null
pointer is an integer *constant* zero converted to a pointer type.  ANSI
does permit a *constant* expression which evaluates to zero, e.g. "1-1",
but that does not remove the requirement that the value be known at
compile time.

>... I had
>once thought of doing an implementation where NULL != 0, but after further
>reading convinced myself the implementation would be invalid.

Not invalid, no; I think there are one or two such.  Unwise, yes, because
many many programs are sloppy about this and have to be fixed to run on
such an implementation.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu