Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!mel.dit.csiro.au!yarra!melba.bby.oz.au!zvs
From: zvs@bby.oz.au (Zev Sero)
Newsgroups: comp.lang.c
Subject: Re: An Ubiquitous C bug
Message-ID: <1991Jan22.024046.16430@melba.bby.oz.au>
Date: 22 Jan 91 02:40:46 GMT
References: <s64421.664471332@zeus> <1991Jan21.083106.7297@tkou02.enet.dec.com>
	<2831@casbah.acns.nwu.edu>
Sender: news@melba.bby.oz.au
Organization: Burdett, Buckeridge and Young Ltd.
Lines: 20
In-Reply-To: hpa@casbah.acns.nwu.edu's message of 21 Jan 91 18:30:23 GMT

Peter = hpa@casbah.acns.nwu.edu (Peter Anvin) 

Peter> Should NULL be all ones?  Performance issues aside, such a
Peter> machine would only need to subtract one when converting an int
Peter> to a pointer, and add one the other way.  In constant
Peter> expressions, such as when using the macro NULL, that can of
Peter> course be done at compile time. 

It would have to be done only at compile time.  Fragments such as:
  int x = 0;
  char *p = (char *)x;
*should* point at location zero if that is a valid address on this
machine, and dereferencing it should give you whatever is at that
address.  *Only* constant expressions evaluating to zero (such as the
macro NULL) represent the null pointer, and these are determined
at compile time.
--
	                                Zev Sero  -  zvs@bby.oz.au
This I say unto you, be not sexist pigs.
		-  The prophetess, Morgori Oestrydingh  (S.Tepper)