the nil pointer is not zero (was TC 2.0 oddity - me or ?)

[Walter Bright]

In article <27636 at mimsy.umd.edu> chris at 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.