Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Failed allocation in constructors?
Message-ID: <55827@microsoft.UUCP>
Date: 13 Jul 90 22:49:57 GMT
References: <9075@goofy.Apple.COM> <42825@apple.Apple.COM> <1990Jul11.180345.21464@Solbourne.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 78

In article <1990Jul11.180345.21464@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes:
|In article <42825@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
|>So, dereferencing zero isn't a bad thing; it's just bad to assume that
|>you always can across all possible hardware architectures that your
|>program might be run on.
|
|Dereferencing "zero" is a bad thing.  "0" is the Nil pointer in C and
|C++.  It is defined to point to an address that doesn't exist (or is
|at least unique).  So if you dereference it, you are asking for
|trouble.
|
|In most implementations of C and C++ a Nil pointer has all its bits
|turned off, but not all implementations do this.  Regardless of the
|implementation, saying "p=0" will get you a Nil pointer.  So if you
|then say *p, that is an error.  However, according to the standard,
|compilers are free to not notify the user this error has occurred.

The bottom of pg 35 of E&S says [short quote:]

A constant expression (@5.19) that evaluates to zero 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.

	* Note that the null pointer need not be represented by the same
	bit pattern as the integer 0.

[unquote]

(Please note: only *constant* expressions that evaluate to zero can be
converted to that pointer commonly called the null pointer.)

I claim it is presently *ill*defined in C++ when, if ever, it is legal
to dereference a null pointer.  I also claim it is presently *ill*defined
in C++ what one gets if one does dereference a null pointer.

By *ill*defined, I mean to say that I believe there is currently a flaw in
the language definition in regards this issue. IE the standardization
committee should address themselves to this issue.

I can only think of one reasonable situation where dereferencing a null
pointer might be a reasonable thing to do -- when creating a reference:

	object* ptrob = 0;

	...

	object& refob = *ptrob	// potentially, a null pointer dereference

	...

	if (&refob)
	{
		refob.DoSomething();
	}
	else
	{
		HandleNullObjectCase();
	}

Readers will immediately respond:  "But you're not *really* dereferencing a
null pointer when assigning it to a reference.  It just *looks* that way
in the C++ code.  In actuality, references are going to be implemented using
pointers, you're really just assigning a pointer to a pointer, and the 
apparent dereference of the pointer is there just to make the type calculus
work right."

All of which, I claim, are issues of code generation, not language
definition.  I still say this situation is presently *ill*defined in the
language.

Compiler writers have pointed out to me, that in practice they can't
stop programmers from creating "null references" this way -- because
you sure as hell don't want to perform a runtime test and trap anytime
a "dereferenced" pointer is used to initialize a reference.

So I say: *why not* explicitly define the language to allow dereferencing
null pointers in the one unique case of initializing a reference, and
define dereferencing null pointers to be undefined in all other cases ???