home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1400 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.5 KB  |  56 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Adding garbage collection to C++
  5. Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  6. Organization: Computer Science, University of Melbourne, Australia
  7. Date: Tue, 18 Aug 1992 10:15:42 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-08-099@comp.compilers>
  10. References: <92-08-052@comp.compilers> <92-08-092@comp.compilers>
  11. Keywords: C, GC
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 41
  14.  
  15. tmb@idiap.ch writes:
  16. >>[C lets you hide pointers in inconvenient ways, e.g. writing them to
  17. >>files or scrambling bytes in unions.]
  18. >
  19. >All the locations where a pointer is converted to an integer (via casts,
  20. >unions, or memcpy) are detectable by the compiler. For any pointer that
  21. >has ever been (mis-)treated in such a way, the corresponding memory can
  22. >simply be exempted from garbage collection (e.g., by recording the pointer
  23. >in some global table searched by the garbage collector).
  24.  
  25. This may be true in theory, but it seems like it would be very difficult
  26. in practice (especially if you allow seperate compilation) and might lead
  27. to memory leaks.
  28.  
  29. Presumeably you have to consider every conversion from (T **) to (void *)
  30. potentially dangerous, since the (void *) could be used to hide away the
  31. (T *) pointer, using memcpy(), fwrite(), or some such.  But such
  32. conversions may be relatively common.
  33.  
  34. For example, if you want to sort an array of strings, then you will
  35. probably pass a (char **) to qsort() where it expects a (void *).
  36. Presumably the compiler is not going to be smart enough to tell the
  37. difference between qsort() and fwrite(), which both take a void *
  38. parameter.  If instead you happened to be using a user-defined sort
  39. function that has not yet been written or compiled, then there is no way
  40. it could tell!  This means that it will have to assume that qsort might
  41. hide a copy of the pointers somewhere, so the compiler must record the
  42. pointers in the global table.
  43.  
  44. Now if you were actually relying on GC to reclaim that memory, you're
  45. stuffed, because the compiler can never be sure that qsort() hasn't
  46. secretly written the addresses to a file, so it has to keep the memory
  47. hanging around.  This is a memory leak.
  48.  
  49. If your GC doesn't prevent memory leaks, not many people will use it :-)
  50.  
  51. -- 
  52. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  53. -- 
  54. Send compilers articles to compilers@iecc.cambridge.ma.us or
  55. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  56.