From bobduff@world.std.com Fri May 17 08:38:58 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA14582; Fri, 17 May 96 08:38:58 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA17617; Fri, 17 May 96 08:39:13 EDT Received: from europe.std.com by sw-eng.falls-church.va.us (8.7.1/) id MAA23871; Fri, 17 May 1996 12:38:08 GMT Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id IAA03826; Fri, 17 May 1996 08:38:54 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA27686; Fri, 17 May 1996 08:38:54 -0400 Date: Fri, 17 May 1996 08:38:54 -0400 From: bobduff@world.std.com (Robert A Duff) Message-Id: <199605171238.AA27686@world.std.com> To: giering@Rational.COM Cc: ada-comment@sw-eng.falls-church.va.us In-Reply-To: <9605160530.AA28135@picard.rational.com> (giering@Rational.COM) Subject: Re: Finalization of Components !topic Controlled components !reference RM95-7.6.1(4) !reference RM95-7.6.1(9) !reference 96-5557.a Ted Giering 96-5-16 !from Bob Duff <> !discussion > This question applies to controlled components of composite objects. > If a component is successfully initialized, must it be finalized on > leaving it's master? Yes. >... The LRM seems to indicate that only objects are > guaranteed to be finalized once they are successfully initialized > (7.6.1(4)). Components are addressed in 7.6.1(9), which says that > they will be finalized after the overall object. It does not say that > an initialized component is guaranteed to be finalized. A component is an object. All objects, including components, are finalized if they were successfully initialized. > GNAT would appear to implemented according to this reading of the LRM, > controlling Initialize/Finalize call pairs at the object level only. > Is this the intent of the LRM? No. It looks like a bug in GNAT, to me. Note that in your test program, an exception is raised during the second initialization (for each sub-test), so only one component is *successfully* initialized. This component should be finalized, but the other(s) should not, and the containing object should not. > procedure Inner_Caller is > begin > Inner_Proc; > raise Init_Error; It looks like it never gets to this raise_statement, since Inner_Proc propagates Init_Error. (Unless I'm misreading the test -- I didn't study it carefully.) - Bob From eachus@spectre.mitre.org Fri May 17 14:26:10 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA19170; Fri, 17 May 96 14:26:10 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA23572; Fri, 17 May 96 14:26:25 EDT Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id SAA02732; Fri, 17 May 1996 18:25:21 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.6.10/8.6.9) with ESMTP id OAA03779; Fri, 17 May 1996 14:26:02 -0400 Received: from localhost (eachus@localhost) by spectre.mitre.org (8.6.4/8.6.4) id OAA15407; Fri, 17 May 1996 14:26:01 -0400 Date: Fri, 17 May 1996 14:26:01 -0400 From: "Robert I. Eachus" Message-Id: <199605171826.OAA15407@spectre.mitre.org> To: ada-comment@sw-eng.falls-church.va.us, kst@thomsoft.com In-Reply-To: <9605151520.AA21158@poseidon.csed.ida.org> (lehman@ida.org) Subject: Re: Another question about pragma List !topic Another question about pragma List !reference RM95 2.8(25) !reference 96-5548.a Keith Thompson 96-5-10 !reference 96-5554.a Keith Thompson 96-5-14 !reference 96-5555.a Dan Lehman 96-5-15 !from Robert I. Eachus 96-5-17 <> !discussion Dan Lehman said: > But I hope that the interpretation given on this (there is not much > help from AI-00578/08) looks to expected use: does one want to disguise > the deliberate omission of listed code, or rather to announce that coded > (by pragma) choice? In the latter case, one expects to see at least the > initial "pragma List(off);"; any listing-restoring "pragma List(on);" is > sort of redundant of the amply apparent (maybe not?) listing itself. I really think that this is more of a URG than ARG issue, but the ARG has been dealing with some of those recently. ;-) My feeling is that the (non-binding) rule should be: If the commpiler is currently producing a listing, the effect of a pragma List(Off) should be that the listing is turned off, no earlier than after the closing parenthesis, and no later than the end of the line containing the semicolon following the pragma. If listing has been suppressed using pragma List(Off), then pragma List(On) should restore printing no earlier than the beginning of the line following the line containing the pragma keyword, and no later than the line following the line containing the semicolon following the pragma. Sounds complex, but what it means is that, in the usual case of each pragma on a line by itself, the pragma List(Off) is printed but not the pragma List(On). The cases where the pragma and or the following semicolon is spread over multiple lines is the kind of pathology that should never be tested. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From stt@dsd.camb.inmet.com Fri May 17 14:54:50 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA19475; Fri, 17 May 96 14:54:50 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA24152; Fri, 17 May 96 14:55:03 EDT Received: from dsd.camb.inmet.com by sw-eng.falls-church.va.us (8.7.1/) id SAA03481; Fri, 17 May 1996 18:53:58 GMT Received: from henning.camb.inmet.com.i2ada by dsd.camb.inmet.com (4.1/SMI-4.1) id AA19468; Fri, 17 May 96 14:54:14 EDT Date: Fri, 17 May 96 14:54:14 EDT From: stt@dsd.camb.inmet.com (Tucker Taft) Message-Id: <9605171854.AA19468@dsd.camb.inmet.com> To: ada-comment@sw-eng.falls-church.va.us, eachus@spectre.mitre.org, kst@thomsoft.com Subject: Re: Another question about pragma List !topic Another question about pragma List !reference RM95 2.8(25) !reference 96-5548.a Keith Thompson 96-5-10 !reference 96-5554.a Keith Thompson 96-5-14 !reference 96-5555.a Dan Lehman 96-5-15 !reference 96-5559.a Robert I. Eachus 96-5-17 !from Tucker Taft 96-5-17 <> !discussion > ... > My feeling is that the (non-binding) rule should be: > ... > Sounds complex, but what it means is that, in the usual case of > each pragma on a line by itself, the pragma List(Off) is printed but > not the pragma List(On). It was always my interpretation of 2.8(25) (and the corresponding paragraph RM83 B.0(7)) that (the lines containing) pragma List(off) and pragma List(on) should *both* be printed, with only the intervening lines missing. Looking at a listing that takes advantage of these pragmas, it is nice to see the pragma List(on), since otherwise the reason for the listing restarting is a bit mysterious (admittedly, not *that* mysterious ;-). As far as a pragma List(off) bracketed by pragma List(off)/List(on) I don't care at all. One reason to show it is it is probably indicating a mistaken impression that pragma list(off)/(on) nest, which they most certainly don't. Another interesting question is whether errors on un-listed lines should be mentioned. That certainly seems more of a URG question (if even that)... In any case, the wording in this paragraph is infuriatingly ambiguous! We inherited it word for word from RM83, B.0(7), by the way, but unfortunately didn't manage to notice its ambiguity at the time... > Robert I. Eachus -Tuck From kst@alsys.com Fri May 17 16:53:34 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA20393; Fri, 17 May 96 16:53:34 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA26117; Fri, 17 May 96 16:53:48 EDT Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id UAA06735; Fri, 17 May 1996 20:52:43 GMT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA04097; Fri, 17 May 96 13:53:18 PDT Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA04843; Fri, 17 May 96 13:52:59 PDT Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA08918; Fri, 17 May 1996 13:52:44 -0700 Message-Id: <9605172052.AA08918@pulsar.telesoft> From: kst@thomsoft.com (Keith Thompson) Date: Fri, 17 May 1996 13:52:43 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ada-comment@sw-eng.falls-church.va.us Subject: Controlled components !topic Controlled components !reference RM95-7.6.1(4) !reference RM95-7.6.1(9) !reference 96-5557.a Ted Giering 96-5-16 !reference RM95-3.3(12) !from Keith Thompson 96-05-17 <> !discussion > If a component is successfully initialized, must it be finalized on > leaving it's master? The LRM seems to indicate that only objects are > guaranteed to be finalized once they are successfully initialized > (7.6.1(4)). Components are addressed in 7.6.1(9), which says that > they will be finalized after the overall object. It does not say that > an initialized component is guaranteed to be finalized. Yes it does, since components are objects. RM95-3.3(12) says that "a component, slice, or view conversion of another object" is an object. The note in AARM-7.6.1(4.a) specifically says that the set of objects to be finalized includes subcomponents.