Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Relationship between C and C++
Message-ID: <34854@news.Think.COM>
Date: 21 Mar 90 05:10:33 GMT
References: <8432@hubcap.clemson.edu> <5200048@m.cs.uiuc.edu> <4869@vanuata.cs.glasgow.ac.uk>
Sender: news@Think.COM
Reply-To: barmar@nugodot.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 30

In article <4869@vanuata.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk (Jack Campin) writes:
>robison@m.cs.uiuc.edu wrote:
>> Can anyone clue me as to the basis for pointer paranoia?
>Garbage collection, for one.  If you try to implement a BCPL-family
>language on a machine/OS with garbage-collected object memory [i.e. a
>storage model a bit more sophisticated than a Turing machine], you have
>real problems identifying what objects are still being referenced when
>pointers can be incremented.

I don't have any such trouble with the C implementation on my Symbolics
Lisp Machine.  On this system, C pointers are implemented as a combination
of an array object reference and an integer byte offset.  Malloc()
allocates such arrays, static variables are implemented as arrays allocated
by the runtime system, and activation records are implemented as arrays
when there are pointers to any of its automatic variables.  When there are
no pointers to the array it becomes garbage.  Pointer arithmetic can never
cause a pointer to jump from one object to another, and attempts to
subtract pointers associated with different objects can often be detected.

On more conventional architectures this could be done using pointer handles
(as in the Mac OS) and an offset.  For efficiency during loops the handle
could be locked, dereferenced, and incremented by the offset; when the loop
is through the offset would be updated and the handle unlocked, at which
time garbage collection can relocate the object and update the handle.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar