Example of null ptr not = 0 ?

Barry Margolin barmar at think.com
Wed Nov 21 10:52:54 AEST 1990


In article <90324.143724DXB132 at psuvm.psu.edu> <DXB132 at 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 <NIL, 0>; 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 <NIL, 0> as the null pointer
(since 0 isn't an array, either).  However, this representation would lead
one to believe that other <integer, integer> 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 at think.com
{uunet,harvard}!think!barmar



More information about the Comp.lang.c mailing list