Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.c Subject: Re: Example of null ptr not = 0 ? Message-ID: <1990Nov20.235254.2921@Think.COM> Date: 20 Nov 90 23:52:54 GMT References: <90324.143724DXB132@psuvm.psu.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 46 In article <90324.143724DXB132@psuvm.psu.edu> writes: >Does there exist a C compiler for any "modern", commercial, 32-bit >(or more :-)) machine (i.e. a machine like you and I use) that uses something >other than zero (real binary zero) to mean "null pointer"? Why not just say in >the spec "a null pointer is zero!" and be done with the whole matter? >It just seems like a trivial academic exercise to talk about it any other way. >(My humble opinion, of course :-)) I don't know what kind of machine you use, but I use a Symbolics Lisp Machine. This is a tagged architecture, in which the hardware and firmware directly support a number of high-level data types. In this environment, pointers are not represented numerically to begin with; they are represented using two separate Lisp objects, the first being an array or NIL, the second being a non-negative integer (the offset into the array). This representation allows attempts to reference beyond the end of an object to be detected, and allows objects to move during garbage collection. A null pointer is represented as the combination ; the attempt to indirect through such a combination is trapped by the array indexing hardware (because NIL isn't an array), and signals a null pointer error. It would be possible to use <0, 0> rather than as the null pointer (since 0 isn't an array, either). However, this representation would lead one to believe that other combinations are also reasonable, which would not be the case. NIL is a much better placeholder, since it doesn't carry such connotations (it's used throughout the language as a generic "empty" value). The hardest part of defining language standards is avoiding parochialism. It's not enough that C be easy to implement on the currently common machines, it should be relatively straightforward to implement it for any general purpose system. Not only would it make the language hard to implement on weird systems that currently exist, but it would also stifle experimentation with other unusual architectures. A language standard should specify all and only what programmers actually *need*; in general, high-level programmers of portable programs don't depend on the precise representation of pointers; what matters is that there is a distinguished null pointer, you can access what a non-null pointer points to. and there is a useful algebra of pointers (PL/I manages without the latter, although pointer arithmetic intrinsics were added as extensions in the Multics PL/I compiler, primarily as a convenience for systems programmers). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar