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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,bf608b8936d68540 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.13.3 with SMTP id d3mr4909965pac.40.1367620571366; Fri, 03 May 2013 15:36:11 -0700 (PDT) MIME-Version: 1.0 Path: bp1ni1480pbd.1!nntp.google.com!news.glorb.com!news.nobody.at!news.albasani.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Accessing finalized values Date: Fri, 3 May 2013 17:36:08 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <143a8db3-c14b-4983-a481-4b998aea42af@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1367620570 19752 69.95.181.76 (3 May 2013 22:36:10 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 May 2013 22:36:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-05-03T17:36:08-05:00 List-Id: wrote in message news:143a8db3-c14b-4983-a481-4b998aea42af@googlegroups.com... >Does anyone have any insight into what happens if a program uses the value >of an object after it has been finalized, but before it ceases to exist? Nothing special (other than protected objects, as Adam notes). This is perfectly legitimate, although arguably pathological. One reason is that it is legal for Finalize to be called on the same object more than once in unusual circumstances (this does not necessarily represent a compiler bug). Moreover, Finalize routines often depend on other data in the program, and that data might already be finalized (imagine the final finalization of a program that's completed). It would be hard to get everything into an order where there was no dependence on things that are already finalized. (This sort of thing can happen in Claw programs, for instance.) The protected object case is a bounded error simply because too many implementations simply crashed in that case (early versions of GNAT did that, it was horrible trying to figure out why Claw programs wouldn't terminate properly - the problem was actually our design bug, but its not helpful to report a bug with a GP fault in the runtime). Making it a bounded error makes it clear that's not an acceptable implementation. The reference to "production code" in AARM 9.4(20.h/2) is talking about the locking used in Claw - which should be obvious from the naming used in the following example. Randy.