Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Re: how has C bitten you?  (Really,
Message-ID: <2745@sun.uucp>
Date: Mon, 2-Sep-85 04:01:30 EDT
Article-I.D.: sun.2745
Posted: Mon Sep  2 04:01:30 1985
Date-Received: Wed, 4-Sep-85 04:49:33 EDT
References: <2000001@eel.UUCP> <4244@alice.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 25

> >>All valid implementations of C guarantee (that a null pointer doesn't
> >>point to anything valid). ... (Yes, there have been (invalid)
> >>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.
> 
> >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 ...
>
> 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.

Yes, that is exactly what I was referring to.  Ideally, if possible,
location zero should literally have nothing there - i.e., your program
should get a segmentation violation if it tries to use the contents of
location 0.  (This hits errant programs upside the head at a nice early
stage in their lives.)  If not, however, you must ensure that it doesn't
have any code or data there - you have to stick a shim in there to prevent
this on separate I&D systems (the startup code acts as a shim in most
non-separate I&D systems).

	Guy Harris