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: 103376,2866100c9a2b8ce7 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Free'ing extended types Date: 1996/04/29 Message-ID: #1/1 X-Deja-AN: 152113669 references: <3183AC75.335C@ehs.ericsson.se> <3184D196.310B@ehs.ericsson.se> <4xpw8qvlau.fsf@lagrange.enst-bretagne.fr> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-04-29T00:00:00+00:00 List-Id: In article <4xpw8qvlau.fsf@lagrange.enst-bretagne.fr>, Laurent Guerby wrote: > Note that the impact of a GC on the "erronenousness" of a program >is interesting. An Ada run-time with GC can simply ignore >Unchecked_Dealocation calls, or do smart thing and raise Program_Error >when an access to a previously deallocated object is performed. In the >first case (do nothing on deallocation) I think the execution is not >erroneous because RM95-13.11.2(16) says : > >"Evaluating a name that denotes a nonexistent object is erroneous. >The execution of a call to an instance of Unchecked_Deallocation is >erroneous if the object was created other than by an allocator for an >access type whose pool is Name'Storage_Pool." > > On a garbage collected implementation, the object is likely to be >"existant" or your GC is wrong ;-). No, I don't think so. The RM says an Unchecked_Deallocated object is non-existent, and deallocating it is erroneous. If you have a GC that thinks it still exists, that's fine, but it's irrelevant to the formal definition of erroneous. (In this case I'd like the gc to raise an exception, but of course that's not required, since erroneous means *anything* can happen, including keeping the officially deallocated object around and using it as usual.) - Bob