Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!jit345!diamond From: diamond@jit345.swstokyo.dec.com (Norman Diamond) Newsgroups: comp.lang.c Subject: Re: An Ubiquitous C bug Message-ID: <1991Jan22.023359.24923@tkou02.enet.dec.com> Date: 22 Jan 91 02:33:59 GMT References: <1991Jan21.083106.7297@tkou02.enet.dec.com> <2831@casbah.acns.nwu.edu> Sender: news@tkou02.enet.dec.com (USENET News System) Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo Lines: 20 In article <2831@casbah.acns.nwu.edu> hpa@casbah.acns.nwu.edu (Peter Anvin) writes: >Should NULL be all ones? Performance issues aside, such a machine would >only need to subtract one when converting an int to a pointer, and add one >the other way. In constant expressions, such as when using the macro NULL, >that can of course be done at compile time. Why would it have to subtract one and add one? At compile time, an integer constant 0 (which has to be evaluated at compile time anyway) in a pointer context (which has to be determined at compile time anyway) would yield a bit-string of all 1's. The library's implementation of free() would either have to be compiled using this compiler, or else be sure that it compares against this compiler's representation of NULL. Casts between pointers and integers (other than compile-time null pointers) are not required to do anything fancy. If I were coding a compiler for a machine where pointers and ints had the same size, I'd just copy the bits. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.