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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Why C++ is successful
Date: 1998/08/07
Message-ID: <dewar.902544337@merv>#1/1
X-Deja-AN: 379050995
References: <dewar.902415458@merv> <6qfhri$gs7$1@nnrp1.dejanews.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 902544738 5000 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-08-07T00:00:00+00:00
List-Id: <comp.lang.ada>

HMMueller says

<<Actually, the problem with new/delete schemes is that the *user*(!!) can
corrupt the heap, e.g. by deleting stack variables:
>>

Sure, that is *precisely* the problem, in a totally protected high level
language (LISP, SNOBOL4, Pure Java etc), you can ensure that the heap
maintains its integrity. The only worry is the correctness of the heap
implementation itself, and this is a problem that can be solved.

But if you allow low level stuff, which is typically a requirement in
embedded applications, then that low level stuff can corrupt pointers.
WIth corrupted pointers around, a perfectly correct garbage collector
can cause unimaginable chaos. 

One time working on the 1108 SPITBOL, we had a case of major heap
corruption, that finally (after looking through several linear feet
of dumps) we realized reflected an error in an imported assembly
language routine, that did not bring things to a grinding halt
till 26 garbage collections later. The small error sort of spread
like a cancer, getting worse on each GC, until it finally crashed.

Now to be fair, this was a mark/sweek/compact collector, and such
collectors are far less robust with respect to this kind of sabotage
than non-compacting collectors.