Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: the nil pointer is not zero (was TC 2.0 oddity - me or ?)
Message-ID: <27636@mimsy.umd.edu>
Date: 13 Nov 90 14:06:20 GMT
References: <7131@castle.ed.ac.uk> <s64421.658489804@zeus>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 28

In article <s64421.658489804@zeus> s64421@zeus.usq.EDU.AU (house ron) writes:
>Zero is actually a perfectly legitimate address, but it got snaffued
>by C to stand for a NULL pointer.

This is true in many *implementations*, but it is not part of C itself.
A nil pointer is a pointer that points to no object.  The actual bit
pattern used to represent a nil pointer at runtime is up to the
implementation, may (but is not required to) depend on the type of
object to which the pointer can point, and is not necessarily all 0
bits.

On computers on which address location zero has `interesting' contents
(e.g., a boot reset vector, or simply regular memory), implementations
are faced with two choices:  either the nil pointer pointer to some
type(s) must not be the bit pattern that means `address location
zero'---typically, this means that, e.g., something like 0x3fc0ee7b
must be used as the bit pattern for nil pointers---or else the
implementation must make sure no object ever happens to be assigned
address 0.  In the former case, one still writes

	char *p = 0;

to put a nil pointer (value 0x3fc0ee7b) into p.

See the Frequently Asked Questions for more details.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris