how has C bitten you? (Really,

[Andrew Koenig]

>>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.

I think the "necessary shim" referred to in the first note quoted
above has nothing to do with a value intended to ensure that *(int*)0
give a defined value.  Rather, it is a dummy variable located at
location 0 designed to ensure the NOTHING ELSE find itself at location
0 by accident!  The trouble with putting a variable at location 0
is that its address will then erroneously appear to be NULL.