Re: backend question

"Nick Maclaren" <>
24 Nov 2002 18:36:29 -0500

          From comp.compilers

Related articles
[7 earlier articles]
Re: backend question (David Chase) (2002-11-20)
Re: backend question (Fermin Reig) (2002-11-24)
Re: backend question (felix) (2002-11-24)
Re: backend question (Fergus Henderson) (2002-11-24)
Re: backend question (2002-11-24)
Re: backend question (Mark) (2002-11-24)
Re: backend question (Nick Maclaren) (2002-11-24)
Re: backend question (Joachim Durchholz) (2002-11-24)
Re: backend question (Nick Maclaren) (2002-11-26)
Re: backend question (Fergus Henderson) (2002-12-01)
Re: backend question (Fergus Henderson) (2002-12-01)
Re: backend question (Nick Maclaren) (2002-12-03)
Re: backend question (2002-12-07)
[2 later articles]
| List of all articles for this month |

From: "Nick Maclaren" <>
Newsgroups: comp.compilers
Date: 24 Nov 2002 18:36:29 -0500
Organization: University of Cambridge, England
References: 02-11-063 02-11-099 02-11-112 02-11-132
Keywords: C, design
Posted-Date: 24 Nov 2002 18:36:29 EST

Fergus Henderson <> wrote:
>"David Chase" <> writes:
>>Standard C doesn't give you enough control to write a precise garbage
>>collector (one that can see all the pointers, and exactly all the
>It does (albeit with a potentially significant performance cost).
>See my recent paper at ISMM'02 [1].

Well, I have looked at it but can't say that I have studied it. I
think that you have assumed quite a few extra constraints - mainly of
the form that the C program is half sane!

For example, it is perfectly conforming for a program to treat a
pointer variable as an array of unsigned char, encrypt that and write
it to disk, overwrite the location, do a lot of memory allocation and
deallocation, read in and decrypt the pointer, use it, and expect the
pointed-to data to still be there!

I don't believe that is a soluble problem, except by never garbage
collecting just because there are no pointers to an object. You CAN
check that a pointer has been abused (e.g. reused after the location
has been freed), but you have to rely on calls to free to tell you
when the space may be released.

While I have never seen the encryption aspect, I have seen program
designs where the only pointer to an in-core construct was held on
disk, under some circumstances.

>>Standard C also gives you less than adequate control of floating point.
>C99 offers some improvements in this area.

For some meaning of the word "improvements". Many of us don't think
that they are improvements, even for the purposes for which they are
intended. But there are certainly extra features, intended for this

Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Tel.: +44 1223 334761 Fax: +44 1223 334679

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.