Xref: utzoo comp.lang.c++:6766 comp.std.c:2581
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++,comp.std.c
Subject: Re: references to dereferenced null pointers
Message-ID: <25F8D2FB.10981@paris.ics.uci.edu>
Date: 10 Mar 90 10:12:12 GMT
References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <52081@microsoft.UUCP>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 75

In article <52081@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>...  Reading the [ C++ ] reference, I find:
>
>"A constant expression that evaluates to 0 is converted to a pointer,
>commonly called the null pointer.  It is guaranteed that this value will
>produce a pointer distinguishable from a pointer to any object."
>
>If the null pointer does not point to any object, then why should
>I assume that I can take the address of that "object" which isn't an
>object?  What guarantee is there that an object that doesn't exist
>even has an address?  And why should that address be "0" ???
>
>It may be that many present systems represent *some* C++ null pointers
>as 32 bits all zero, but this is not the same as saying making such
>an assumption is portable to future systems.  In particular, a system
>with [hardware support for] typed pointers would not have null pointers
>represented as 32 bits all zero.
>
>Also, note that the "0" that creates a null pointer must be a constant
>expression -- allowing a compiler to construct a special representation
>for null pointers at compile time.  Also note:  This means the fairly
>common "C" coding technique of assigning to a pointer a runtime expression
>that evaluates to zero is not guaranteed to be legal.  And assigning
>one null pointer to a different type of pointer need not keep the same
>bit representations.

Jim,

I see that I should not have been nearly so cavalier in response to your
questions about "null references".  You raise some important questions.

Note however that many of these questions apply equally well to the C standard.
For instance, in C, should the following be considered legal?

	void *vp;

	vp = 0;
	vp = &(*vp);

Also, you noted the obscure restriction that a null pointer must be
something created from "an integral constant expression with the value 0"
(see ANSI C standard 3.2.2.3).  This could be an issue for both C and
C++, since it would seem to place in doubt the validity of the following:

	int nil ()
	{
		return 0;
	}

	...

		void *vp;

		vp = (void *) nil ();

I am cross posting this to comp.std.c just to see if anyone there will
clarify for us the legality (or illegality) of the two examples above
(and possibly also the relevant rationale).

>So, I interpret your response to be: "This is presently undefined,
>but who cares, its trivial."  Well, I care, and I claim its not
>a trivial issue, but rather has important impact for the mapping of
>C++ onto systems with typed pointers.  If making null references
>*is* legal, let someone in the know state so uneqivocally, and I
>can get on with my programming.  I'd like to see this made explicetly
>legal -- but doing so may have a sharp negative impact on systems
>with typed pointers.

At the very least, these issues should be clarified a bit, both for C++
and for C.


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.