Re: Adding garbage collection to C++

fjh@cs.mu.OZ.AU (Fergus Henderson)
Fri, 14 Aug 1992 08:45:36 GMT

          From comp.compilers

Related articles
Adding garbage collection to C++ Dain.Samples@UC.EDU (1992-08-11)
Re: Adding garbage collection to C++ tmb@arolla.idiap.ch (1992-08-12)
Re: Adding garbage collection to C++ mw@ki.fht-mannheim.de (1992-08-13)
Re: Adding garbage collection to C++ kelvin@kickapoo.cs.iastate.edu (1992-08-13)
Re: Adding garbage collection to C++ fjh@cs.mu.OZ.AU (1992-08-14)
Re: Adding garbage collection to C++ jos@and.nl (1992-08-14)
Re: Adding garbage collection to C++ henry@zoo.toronto.edu (1992-08-14)
Re: Adding garbage collection to C++ bill@amber.ssd.csd.harris.com (1992-08-14)
Re: Adding garbage collection to C++ pardo@cs.washington.edu (1992-08-15)
Re: Adding garbage collection to C++ tmb@idiap.ch (1992-08-17)
Re: Adding garbage collection to C++ tmb@idiap.ch (1992-08-17)
[6 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 14 Aug 1992 08:45:36 GMT
References: 92-08-052 92-08-063
Keywords: C, GC

mw@ki.fht-mannheim.de (Marc Wachowitz) writes:


>Thomas M. Breuel <tmb@arolla.idiap.ch> wrote:
>: As far as I can tell, ANSI-C and C++ are both fully garbage collectable
>: within the current language standard.
>
>At least you would have to be very careful when the programmer copies the
>value of the last pointer to some heap object to some memory region (e.g.
>an unsigned char[]) and changes the order of the array elements, then
>destroys the pointer. No more live reference is detectable by the
>collector, but the programmer may copy back the pointer value (again
>changing the byte order) and ... :-) I guess such manipulations would be
>possible with the current standard.


Yes, I have thought about exactly the same problem.
Is there way around this, Thomas?


    void f() {
     int i;
void *p=malloc(666);
char hide_p[sizeof (void *)];


memcpy(hide_p,&p,sizeof (void *)); // copy pointer into char array
swap(hide_p[0],hide_p[1]); // rearrange array
p = 0;


// allocate lots of memory to force garbage collection
for (i=0;i<10000;i++) malloc(10000);


swap(hide_p[0],hide_p[1]); // restore array and
memcpy(&p, hide_p, sizeof (void *)); // copy back to pointer


// now use p
memset(p,0,666);
        }


>[It is my impression that an ANSI C program is allowed to copy a pointer to
>a long and later back to a pointer of the same type. This sort of thing
>makes it hard to find all the live data. -John]


This is not really a problem for conservative garbage collectors which
scan through the C stack, since the long will still be on the stack and
will thus be considered a reference.


Also while a program is allowed to copy a pointer to a long and back
again, it is not allowed to depend on the results! Conversion from
pointers to long and vice versa is implementation defined, I think, and
anyway there is no guarantee in ANSI C that long wil be large enough to
hold a pointer.


Unfortunately I think that it *is* fine to copy a pointer to an array of
char and back again and to depend on the original pointer being restored.
--
Fergus Henderson fjh@munta.cs.mu.OZ.AU
[My copy of the C standard is in the mail, so I'll wait until it arrives
before further pontificating on legal type casts. frumious!pat@uunet.ca
sent in a similar GC-resistant example that writes pointers out to
temporary files. -John]
--


Post a followup to this message

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