CVS difference for ai05s/ai05-0190-1.txt

--- ai05s/ai05-0190-1.txt	2011/01/25 04:34:20	1.7
+++ ai05s/ai05-0190-1.txt	2011/01/25 08:00:08	1.8
@@ -1375,3 +1375,250 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Thursday, January 20, 2011  1:08 AM
+
+I'm putting the rules for AI05-0051-1 into the standard, and in writing the
+reason for the change to 7.6.1(11/2), I realized that it reason seems bogus
+(now). The discussion for AI05-0051-1 says:
+
+On a separate but related issue, this AI also recommends we relax the rules for
+order of finalization of objects (other than coextensions) created by anonymous
+allocators, since tying them to a particular freezing point is tricky, and
+doesn't seem to be of great value to the user. All that really matters is that
+they get finalized in the master determined by their accessibility level, and
+that is already specified by 7.6.1(4). For named access types, there is the
+concern that their collections be finalized before any corresponding storage
+pool object gets finalized, but there is no similar consideration for
+non-coextension anonymous allocations, since they always use the "default"
+storage pool.
+
+Unfortunately, whoever wrote this (sounds like Tucker to me) never read
+AI05-0190-1. (In his defense, it probably hadn't been proposed yet.) It would
+appear that the last sentence is completely false:
+
+    procedure Mess_It_Up is
+        Super : My_Storage_Pool;
+        pragma Default_Storage_Pool(Super);
+
+        Obj : access Some_Controlled_Type := new Some_Controlled_Type'(...);
+    begin
+        ...
+
+The rewrite of 7.6.1(11/2) would allow the access object Obj to be finalized at
+any point during the finalization of the master Mess_It_Up. However, if that
+happened *after* the finalization for Super, and that finalization freed the
+memory of Super (which is likely), the finalization would be erroneous. That
+makes no sense, especially as the current language would have no such problem.
+
+There seem to be three fixes (in order of my preference):
+
+(1) Simply drop the change to 7.6.1(11/2) from AI05-0051-1. The justification
+    for the change was weak to begin with, and with the use of pragma
+    Default_Storage_Pool, it is downright wrong.
+
+(2) Make it illegal for pragma Default_Storage_Pool to refer to an object in the
+    same scope as the pragma. That is, for this case to be legal, the storage
+    pool would have to be global. Then the order of finalization is irrelevant.
+    However, that seems to disallow some important usage cases. Most
+    importantly, it would prevent using the pragma to force the entire program
+    to use a special storage pool (since a global Default_Storage_Pool pragma
+    would necessarily be disallowed).
+
+(3) Make pragma Default_Storage_Pool not apply to anonymous access types. But
+    that was one of the primary purposes of the pragma (to give a way to specify
+    a storage pool for an anonymous access type). It would make just as much
+    sense to forget the pragma altogether (which is solution 3B).
+
+So I'm in favor of (1). The justification for the change is pretty weak, and
+mainly seems to be an attempt to prevent ACATS test authors from dreaming up
+tests of the finalization order of allocated anonymous access types. It's hard
+to imagine a well-designed program that would care; but if one exists, this
+laisse faire finalization probably wouldn't work right anyway.
+
+Thoughts??
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 20, 2011  1:13 AM
+
+I should also have mentioned that I had to document this as an inconsistency
+with Ada 2005 (since the behavior of programs could change from Ada 2005 to Ada
+2012, with the caveat that a program that could tell would be pretty fragile
+anyway, so there shouldn't be many of them). It was hard for me to justify that
+inconsistency, since there doesn't seem to be an important technical reason for
+the change -- its just easier for implementers.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, January 20, 2011  1:26 PM
+
+> ...
+>
+> There seem to be three fixes (in order of my preference):
+>
+> (1) Simply drop the change to 7.6.1(11/2) from AI05-0051-1. The
+> justification for the change was weak to begin with, and with the use
+> of pragma Default_Storage_Pool, it is downright wrong.
+
+This "fix" seems reasonable.  My only worry is the assertion in the !discussion
+that "tying them to a particular freezing point is tricky".  Do we know what
+some of the tricky cases are and how hard they'll be to implement properly? Of
+course, if it's too tricky, then implementations will just do whatever they feel
+like doing (and in practice it may not matter much, as long as it's not
+tested:-).
+
+> (2) Make it illegal for pragma Default_Storage_Pool to refer to an
+> object in the same scope as the pragma. That is, for this case to be
+> legal, the storage pool would have to be global. Then the order of
+> finalization is irrelevant. However, that seems to disallow some
+> important usage cases. Most importantly, it would prevent using the
+> pragma to force the entire program to use a special storage pool
+> (since a global Default_Storage_Pool pragma would necessarily be disallowed).
+
+That sounds like a no-go.
+
+> (3) Make pragma Default_Storage_Pool not apply to anonymous access types.
+> But that was one of the primary purposes of the pragma (to give a way
+> to specify a storage pool for an anonymous access type). It would make
+> just as much sense to forget the pragma altogether (which is solution 3B).
+
+Also not appealing.
+
+> So I'm in favor of (1). The justification for the change is pretty
+> weak, and mainly seems to be an attempt to prevent ACATS test authors
+> from dreaming up tests of the finalization order of allocated
+> anonymous access types. It's hard to imagine a well-designed program
+> that would care; but if one exists, this laisse faire finalization probably wouldn't work right anyway.
+>
+> Thoughts??
+
+As another possibility, why couldn't we allow the ordering of finalization to be
+relaxed, but subject to not occurring later than the finalization of the
+associated storage pool?  Or would that be too hard to word properly for some
+reason?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 20, 2011  4:18 PM
+
+...
+> > There seem to be three fixes (in order of my preference):
+> >
+> > (1) Simply drop the change to 7.6.1(11/2) from AI05-0051-1. The
+> > justification for the change was weak to begin with, and with the
+> > use of pragma Default_Storage_Pool, it is downright wrong.
+>
+> This "fix" seems reasonable.  My only worry is the assertion in the
+> !discussion that "tying them to a particular freezing point is
+> tricky".  Do we know what some of the tricky cases are and how hard
+> they'll be to implement properly?
+> Of course, if it's too tricky, then implementations will just do
+> whatever they feel like doing (and in practice it may not matter much,
+> as long as it's not tested:-).
+
+I think the "tricky" part is that the collection might be logically inside of
+some other entity (such as a subprogram). I know this happened to me in one of
+the new ACATS programs: an anonymous access type tried to generate a task master
+object that ended up inside of the subprogram that was being declared.
+
+But this can happen for named access types as well (because the freezing point
+can be inside of some other construct, such as the specification for a
+subprogram body), so I don't see the big deal about anonymous access types
+*only*. The compiler needs to be able to move this stuff somewhere else in
+either case. Maybe it's a little more common for anonymous access, but that only
+helps if you are going to intentionally leave a bug in your compiler and hope
+that no one hits it. Doesn't seem a like a compelling reason to me.
+
+As far as it being "tricky", that's because it depends on freezing (always a bad
+idea, because it is hard to reason about). But that's true for all access types,
+so it hard to imagine how it helps to have different rules for named and
+anonymous access types.
+
+...
+> > So I'm in favor of (1). The justification for the change is pretty
+> > weak, and mainly seems to be an attempt to prevent ACATS test
+> > authors from dreaming up tests of the finalization order of
+> > allocated anonymous access types. It's hard to imagine a
+> > well-designed program that would care; but if one exists, this
+> > laisse faire finalization probably wouldn't work right anyway.
+> >
+> > Thoughts??
+>
+> As another possibility, why couldn't we allow the ordering of
+> finalization to be relaxed, but subject to not occurring later than
+> the finalization of the associated storage pool?
+> Or would that be too hard to word properly for some reason?
+
+I suppose we could do that, but one then has to wonder why it applies only to
+*anonymous* access types. Whether the order matters or not would seem to apply
+equally to named and anonymous access types. If it isn't important for anonymous
+types, it shouldn't be important for named types, either.
+
+Indeed, I would prefer that the finalization occurred at the point of the
+declaration of the access type [*any* access type] unless that would occur after
+the finalization of the storage pool. (That would be a lot easier to reason
+about than either some unspecified place or at some freezing point which is
+itself hard to determine.) The problem is that it is inconsistent, and we don't
+have any serious problem that would justify introducing an inconsistency. So I
+think we should simply forget this change.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 20, 2011  5:44 PM
+
+> There seem to be three fixes (in order of my preference):
+ >
+ > (1) Simply drop the change to 7.6.1(11/2) from AI05-0051-1.
+
+Don't we still need to say that the rule given in 7.6 for finalization of
+objects created by anonymous-access-typed allocators doesn't apply to
+coextensions (which have their own rule about when they get finalized)?
+
+If we simply drop the change as you suggest, it seems that we end up with two
+(inconsistent) rules about when coextensions are finalized.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 20, 2011  5:50 PM
+
+I suppose you are right, but if that was the reason for the change, it ought to
+have been mentioned somewhere. And just adding "that are not coextensions of
+some other object" to the access type wording would do the trick, without any
+inconsistency.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 20, 2011  5:57 PM
+
+> I suppose you are right, but if that was the reason for the change, it
+> ought to have been mentioned somewhere.
+
+Agreed. Fixing coextension finalization may have been an unintended (but still
+desirable) consequence of this change.
+
+> And just adding "that are not coextensions of some other object" to
+> the access type wording would do the trick, without any inconsistency.
+
+Agreed.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 20, 2011  7:49 AM
+
+> As another possibility, why couldn't we allow the ordering of
+> finalization to be relaxed, but subject to not occurring later than
+> the finalization of the associated storage pool?  Or would that be too
+> hard to word properly for some reason?
+
+This seems preferable to me.
+
+****************************************************************
+