Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!sumax!amc-gw!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: the nil pointer is not zero (was TC 2.0 oddity - me or ?)
Message-ID: <164@nazgul.UUCP>
Date: 16 Nov 90 21:45:02 GMT
References: <7131@castle.ed.ac.uk> <s64421.658489804@zeus> <27636@mimsy.umd.edu>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 22

In article <27636@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
/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.

Or a third method, commonly used on the PC: 0 is both the NULL pointer
*and* is a valid address. If you wish to poke into the interrupt vector
table, nothing stops you from doing this (and it works fine):
	long far *p = 0;
	*p = whatever;
I'm also told that this solution is used on that Prime computer which seems
to be the only one where NULL!=0. All that is necessary is to adjust malloc
and the layout of the code and data so that it never sits on 0.

I think the ANSI C committee missed the boat on this. Thousands of hours
of wasted time, confusion, and net debate would have been eliminated if
NULL had been fixed at all bits 0.