Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: pointer sizes, was: Re: What does char **ch mean?
Message-ID: <5805@goanna.cs.rmit.oz.au>
Date: 17 May 91 09:00:11 GMT
Article-I.D.: goanna.5805
References: <1991May4.062007.3264@weyrich.UUCP> <16071@smoke.brl.mil> <1991May15.234259.2613@research.canon.oz.au>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 21

In article <1991May15.234259.2613@research.canon.oz.au>, andy@research.canon.oz.au (Andy Newman) writes:
> I remember great concern by one compiler writer over what value should be
> stored for null pointers [on transputers].
> The person used 0 so as not to break all the source
> that assumes that null pointers are 0. This threw away half the address
> space of the machine (only 2Gb [on a 32 bit machine], what a bummer!).

There is no reason why placing NULL at address 0 should throw away
anything more than one byte of the address space.  C requires a guarantee
that no user-declared variable and no object allocated by malloc() and
friends will ever live at the address which NULL converts to.  It does
_not_ require that NULL convert to the lowest address, and in fact doesn't
define pointer comparison except within (or at the top end of) a single
object.

I've used a 68000-lookalike where user address space was negative, so
that 0 was not in the user's accessible address space.  On that machine,
NULL converted to 0, not to 0x80000000.  That was sensible.

-- 
There is no such thing as a balanced ecology; ecosystems are chaotic.