Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site eel.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!eel!lee
From: lee@eel.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: how has C bitten you?  (Really,
Message-ID: <2000001@eel.UUCP>
Date: Wed, 28-Aug-85 21:52:00 EDT
Article-I.D.: eel.2000001
Posted: Wed Aug 28 21:52:00 1985
Date-Received: Sat, 31-Aug-85 08:21:24 EDT
References: <259@watmum.UUCP>
Lines: 24
Nf-ID: #R:watmum:-25900:eel:2000001:000:1286
Nf-From: eel!lee    Aug 28 21:52:00 1985


>>Gee....and I thought a zero pointer was guaranteed not to point to
>>anything valid (K&R says this).

>All valid implementations of C guarantee this.  Obviously, the
>implementation of C that this was done on is not valid.  He should complain
>to the vendor.  (Yes, there have been such implementations; one well-known
>chip maker's first UNIX release didn't put the necessary shim at data
>location 0 on a separate I&D space program.  They fixed it shortly
>afterwards.)

Speaking of issues that have been beaten to death!  K&R says only that the
value 0 is distinguishable from pointers that point to objects, and that
therefore the value zero is not a "valid" pointer.  It certainly does not
say that the 0 pointer will give you the "null" or empty value of any
object, and in particular it does not promise that there will be an integer
zero if you dereference (int*)0, or a character zero if you dereference
(char*)0, nor a memory fault if you reference (foo*)0.

NO, you cannot depend upon the value obtained by dereferencing ANY pointer
that has been assigned the value zero.  It does not point to any object;
the implementation of C does not guarantee  to protect you from erroneously
trying to access that object and the result is unpredictable over various
implementations.