From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.misc:1375 comp.lang.modula2:736 comp.lang.ada:1090 Path: utzoo!mnetor!uunet!husc6!rice!titan!boehm From: boehm@titan.rice.edu (Hans Boehm) Newsgroups: comp.lang.misc,comp.lang.modula2,comp.lang.ada Subject: Re: From Modula to Oberon Message-ID: <628@ra.rice.edu> Date: 30 Mar 88 22:41:07 GMT References: <145@krafla.rhi.hi.is> <272@fang.ATT.COM> <429@zap.UUCP> <8196@sol.ARPA> Sender: usenet@rice.edu Reply-To: boehm@titan.rice.edu (Hans Boehm) Organization: Rice University, Houston Summary: Manual storage management disasters List-Id: It seems to me that the C++ approach to storage management is at best a partial solution. Admittedly it succeeds at automatically deallocating objects in trivial cases. For some applications this is, no doubt, sufficient. But consider a case as simple as implementing a stack type, whose underlying representation is a linked list. Assume this type includes a non-destructive "pop" operation that returns a new stack one shorter than the old one. The original stack is left intact. ("Pop" can of course be implemented as the "tail" operation on linked lists.) Should the head of the original linked list be deallocated? Is it reasonable to make that the caller's responsibility? Certainly not, since it's not supposed to know anything about the representation of stacks. After all, I could be copying arrays. The stack implementation could reference count, but that's more tedious, error prone, and probably slower than a good garbage collector. It also doesn't always work. My experience is that any attempt at manipulation of interesting linked structures in a language that doesn't support real automatic storage management will either fail, or waste large amounts of debugging time. (My experience includes a (working) 40,000 line compiler, written in C, that manipulates a reference counted syntax "tree", or more accurately, a reference counted syntax graph.) Normally, it is extremely difficult to track down bugs created by premature deallocation. When such bugs are finally removed, the resulting programs normally include a substantial number of storage leaks. Some recent experiments by Mark Weiser and myself with retrofitting a garbage collector to existing C programs, verify the latter point. (The garbage collector should never free anything since that was the programmers responsibility. It does. In other people's code. Our paper on this should appear in Software P&E shortly.) Mike Caplinger reported similar results for another application at the last USENIX conference, I believe. We have resurrected C code with storage management bugs by linking it against a garbage collector (which in the case of C doesn't always work either, but it has a better track record than manual storage management). There are arguably cases in which a garbage collector is undesirable, notably in the presence of severe real-time constraints. But even in such a situation, I would want a garbage collector during debugging to help me track down storage leaks. Hans-J. Boehm boehm@rice.edu Computer Science Dept. Rice University Houston, TX 77251-1892