home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1370 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.0 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!jvnc.net!rutgers!faatcrl!iecc!compilers-sender
  2. From: fjh@cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Adding garbage collection to C++
  5. Keywords: C, GC
  6. Message-ID: <92-08-069@comp.compilers>
  7. Date: 14 Aug 92 08:45:36 GMT
  8. References: <92-08-052@comp.compilers> <92-08-063@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: fjh@cs.mu.OZ.AU (Fergus Henderson)
  11. Organization: Computer Science, University of Melbourne, Australia
  12. Lines: 61
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. mw@ki.fht-mannheim.de (Marc Wachowitz) writes:
  16.  
  17. >Thomas M. Breuel <tmb@arolla.idiap.ch> wrote:
  18. >: As far as I can tell, ANSI-C and C++ are both fully garbage collectable
  19. >: within the current language standard.
  20. >
  21. >At least you would have to be very careful when the programmer copies the
  22. >value of the last pointer to some heap object to some memory region (e.g.
  23. >an unsigned char[]) and changes the order of the array elements, then
  24. >destroys the pointer.  No more live reference is detectable by the
  25. >collector, but the programmer may copy back the pointer value (again
  26. >changing the byte order) and ... :-) I guess such manipulations would be
  27. >possible with the current standard.
  28.  
  29. Yes, I have thought about exactly the same problem.
  30. Is there way around this, Thomas?
  31.  
  32.   void f() {
  33.       int i;
  34.     void *p=malloc(666);
  35.     char hide_p[sizeof (void *)];
  36.  
  37.     memcpy(hide_p,&p,sizeof (void *)); // copy pointer into char array
  38.     swap(hide_p[0],hide_p[1]);       // rearrange array
  39.     p = 0;
  40.  
  41.     // allocate lots of memory to force garbage collection
  42.     for (i=0;i<10000;i++) malloc(10000);
  43.  
  44.     swap(hide_p[0],hide_p[1]);        // restore array and
  45.     memcpy(&p, hide_p, sizeof (void *));    // copy back to pointer
  46.  
  47.     // now use p
  48.     memset(p,0,666);
  49.     }
  50.  
  51. >[It is my impression that an ANSI C program is allowed to copy a pointer to
  52. >a long and later back to a pointer of the same type.  This sort of thing
  53. >makes it hard to find all the live data. -John]
  54.  
  55. This is not really a problem for conservative garbage collectors which
  56. scan through the C stack, since the long will still be on the stack and
  57. will thus be considered a reference.
  58.  
  59. Also while a program is allowed to copy a pointer to a long and back
  60. again, it is not allowed to depend on the results! Conversion from
  61. pointers to long and vice versa is implementation defined, I think, and
  62. anyway there is no guarantee in ANSI C that long wil be large enough to
  63. hold a pointer.
  64.  
  65. Unfortunately I think that it *is* fine to copy a pointer to an array of
  66. char and back again and to depend on the original pointer being restored.
  67. -- 
  68. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  69. [My copy of the C standard is in the mail, so I'll wait until it arrives
  70. before further pontificating on legal type casts.  frumious!pat@uunet.ca
  71. sent in a similar GC-resistant example that writes pointers out to
  72. temporary files. -John]
  73. -- 
  74. Send compilers articles to compilers@iecc.cambridge.ma.us or
  75. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  76.