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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6b1a1ed8b075945 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!r34g2000hsd.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Mon, 10 Sep 2007 05:10:59 -0700 Organization: http://groups.google.com Message-ID: <1189426259.744781.118590@r34g2000hsd.googlegroups.com> References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189369871.672082.162750@50g2000hsm.googlegroups.com> NNTP-Posting-Host: 128.141.44.117 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1189426260 21632 127.0.0.1 (10 Sep 2007 12:11:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 10 Sep 2007 12:11:00 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: r34g2000hsd.googlegroups.com; posting-host=128.141.44.117; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1857 Date: 2007-09-10T05:10:59-07:00 List-Id: On 10 Wrz, 00:43, Simon Wright wrote: > I'm not sure that I'd be scared, precisely. > > If this was a safety-related program I would expect some serious test > effort, which would probably discover the mistake; or maybe formal > methods would be appropriate. Sure. Or even better - forget about dynamic memory and solve these problems by avoiding them. > Even then, a safety-related _system_ ought to have some strategy for > recovering from such a runtime error. Of course - and imagine that it can recover from the error that caused the exception. But the problem is with memory leak - how can you recover from memory leak if you don't have any pointer to the memory block that was already allocated? > In any case, why would the runtime system need to guarantee memory > recovery when it can hardly be expected to recover from the failed > design that led to the situation in the first place? Assume that it does recover from the failure that has led to the exception. How to recover from the resulting memory leak? > I don't believe > there's any sensible recovery action to be taken -- the program's > state is corrupt already. Why do you think it is necessarily corrupt? Just reading to the end of the file causes an exception. Using a network connection that got broken can cause an exception. In both cases there is no corruption of the program state and reasonable recovery (or graceful degradation of the functionality) can be provided. How to handle the memory leak? -- Maciej Sobczak http://www.msobczak.com/