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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0252-1.txt

--- ai05s/ai05-0252-1.txt	2011/06/20 04:55:19	1.2
+++ ai05s/ai05-0252-1.txt	2011/07/25 05:58:36	1.3
@@ -1,6 +1,7 @@
-!standard 13.11.4(0)                              11-06-16    AI05-0252-1/01
-!standard 13.11.5(0)
+!standard 13.11.4(0)                              11-07-24    AI05-0252-1/02
 !class Amendment 11-06-16
+!status Amendment 2012 11-07-24
+!status ARG Approved 6-0-5  11-06-26
 !status work item 11-06-16
 !status received 11-05-13
 !priority Low
@@ -8,7 +9,8 @@
 !subject Questions on subpools
 !summary
 
-**TBD.
+A storage pool that supports subpools cannot be specified as part of a
+formal parameter or a dereference of a non-library-level generic access type.
 
 !question
 
@@ -32,12 +34,48 @@
 
 !proposal
 
-** TBD.
+(See wording.)
 
 !wording
 
-** TBD.
+Add after 13.11.4(7/3):
 
+   -- The following operations are intended for pool implementers:
+
+Modify 13.11.4(22/3):
+
+The accessibility level of a subpool access type shall not be statically deeper
+than that of the storage pool object. {If the specified storage pool object is a
+storage pool that supports subpools, then the name that denotes the object shall
+not denote part of a formal parameter, nor shall it denote part of a dereference
+of a value of a non-library-level general access type. In addition to the places
+where Legality Rules normally apply (see 12.3), these rules also apply in the
+private part of an instance of a generic unit.}
+
+Replace 13.11.4(23/3) by:
+
+When an access type with a specified storage pool is frozen (see 13.14), if the
+tag of the storage pool object identifies a storage pool that supports subpools,
+the following checks are made:
+
+* the name used to specify the storage pool object does not denote part of a
+  formal parameter nor part of a dereference of a value of a non-library-level
+  general access type; and
+
+* the accessibility level of the access type is not deeper than that of the
+  storage pool object.
+
+Program_Error is raised if either of these checks fail.
+
+Add after AARM 13.11.4(23.a/3):
+
+We also disallow the use of formal parameters and dereferences of
+non-library-level general access types when specifying a storage pool object if
+it supports subpools, because the "apparent" accessibility level is potentially
+deeper than that of the underlying object. Neither of these cases is very likely
+to occur in practice.
+
+
 !discussion
 
 For (1), the model of AI05-0111-3 is that subpools are not logically reused.
@@ -48,25 +86,28 @@
 nulling the handle after use makes sense. (It also is similar to what
 Unchecked_Deallocation does.)
 
-We could adopt a different model instead where subpools can be reused (although
-it would be completely up to pool implementers to provide such operations). In
-that case, it would make sense to not null out subpool handles (so they are
+We could have adopted a different model instead where subpools can be reused
+(although it would be completely up to pool implementers to provide such operations).
+In that case, it would make sense to not null out subpool handles (so they are
 ready for reuse if desired). To reuse a subpool, it still would necessary to
 call Set_Pool_for_Subpool (as that routine also reinitializes the data
-structures necessary to handle finalization).
+structures necessary to handle finalization). But there doesn't seem to be
+enough advantage to this model to adopt it.
+
+No one identified any problems with the added text (question (2)).
 
-(3) seems to require a purpose-built legality rule or runtime check. Such a
-parameter could never pass the accessibility check for a local access type
-(and it wouldn't be visible for any other kind of access type), so we can
-ban it outright. But we would have to cover Root_Storage_Pool'Class as well,
-and that would be somewhat incompatible.
+A similar problem to question (3) occurs for dereferences of non-library-level
+general access types. The real object can be longer-lived than the access
+type. Thus we adopt rules to ban both of these cases (neither is common).
+We need dynamic rules in the case that the type is Root_Storage_Pool'Class,
+since we don't want a compatibility problem (that is legal in Ada 2005).
 
 ===========================
 
 Bob asked four additional questions in his letter ballot comments. (Actually
-six, but one depends on another that is unlikely to be changes, and another
+six, but one depends on another that is unlikely to be changed, and another
 actually was something that Bob himself had changed in a previous draft.)
-These don't seem worth considering now; here's the questions and the editor's
+These don't seem worth considering now; here are the questions and the editor's
 replies:
 
 [A] Why do we have to do everything via handles anyway? What's wrong with
@@ -77,8 +118,8 @@
 the pool, and it is the pool implementer's responsibility to ensure the
 objects live as long as the pool (unless deallocated). If this is violated,
 the normal dangling pointer rules cover any problems (and these occur mostly
-from are mistakes by the pool implementer - caused by premature deallocation
-of subpool objects; it is highly unlikely that use of deallocated subpool
+from mistakes by the pool implementer - caused by premature deallocation
+of subpool objects - it is highly unlikely that use of deallocated subpool
 handles by clients will not be detected, and pool implementers can reduce that
 to zero).
 
@@ -88,7 +129,7 @@
 However, if the subpool objects are managed by the client rather than the
 pool implementer, then dangling subpools become much more common and the
 pool implementer cannot do anything to prevent problems. Moreover, we now
-have problems because access types can contain subpools whose object have to
+have problems because access types can contain subpools whose objects have to
 disappear before the type.
 
 [B] The idea that "new" can call either Allocate or Allocate_From_Subpool,
@@ -124,7 +165,7 @@
 
 [D] There might be a better answer than "raise Program_Error" when
     tasks are allocated in subpools.  But Bob can't determine that
-    without some serious study of our [AdaCore's] runtimes.  And Randy has
+    without some serious study of our [AdaCore's] runtimes. And Randy has
     completely a opposing viewpoint on this.
 
 I'm not sure what is opposing about my viewpoint; my personal viewpoint is
@@ -141,12 +182,24 @@
 
 In any case, significant change in this area requires both prototyping in
 various compiler runtimes and willingness of the ARG to adopt a more complex
-solution -- the first cannot be done at this meeting and the latter is unlikely.
+solution -- the first cannot be done at this meeting and the latter is unlikely,
+at least for Ada 2012 (that may change as more experience with subpools is
+gained).
 
+!corrigendum 13.11.4(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
 !ACATS test
 
-** TBD.
+Add an ACATS B-Test to check the new legality rule.
 
+!ASIS
+
+No impact on ASIS.
+
 !appendix
 
 From: Bob Duff
@@ -494,3 +547,199 @@
 Anyway, I'll put this into the subpool discussion AI for the meeting.
 
 ****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 20, 2011  6:35 AM
+
+> The accessibility check at (A) will pass, because A_Pool is treated as
+> if it is local for the purposes of accessibility (so we don't have to
+> pass runtime accessibility levels). But this means that A_Acc and
+> Some_Pool are in different masters. And the finalization of the
+> allocated objects of type A_Acc might not occur until Some_Pool is
+> finalized -- which means the finalization is going to access a non-existent local
+> variable. Ouch!
+
+Good catch.
+
+> I've thought of a number of ways to fix this. It should be noted that
+> such a pool as a parameter will never work for a pool that supports
+> subpools. So a straight legality rule would work -- except that it
+> would be incompatible (since pools of Root_Storage_Pool'Class have to
+> be assumed to be able to have subpools). (The incompatibility would be
+> pretty unlikely, as this would be an unusual thing to do.) A runtime
+> check would work, but it is a bit weird, especially for a case this unlikely.
+
+I agree with the above comments.
+
+> Exactly how to word a rule seems interesting, too. It would be best to
+> do something to "fix" the accessibility levels for cases like this
+> (parameters are not *quite* the same level as local objects), but that
+> seems very messy (I tried it for aliased parameters, and I managed to
+> introduce lots of bugs, so we abandoned it).
+
+I don't understand this approach.  I guess we'll talk about it in the meeting.
+
+> Anyway, I'll put this into the subpool discussion AI for the meeting.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 20, 2011 12:20 PM
+
+> Good catch.
+
+It's your fault, really. I was trying to figure out how you could write a pool of
+Root_Storage_Pool'Class. One obvious way to do that would be to pass it as a
+subprogram parameter (generic parameters being less interesting because of macro
+substitution implementations). But that should never be legal, the accessibility check
+should always fail... oh-oh, foot odor! :-)
+
+...
+> > Exactly how to word a rule seems interesting, too. It would be best
+> > to do something to "fix" the accessibility levels for cases like
+> > this (parameters are not *quite* the same level as local objects),
+> > but that seems very messy (I tried it for aliased parameters, and I
+> > managed to introduce lots of bugs, so we abandoned it).
+>
+> I don't understand this approach.  I guess we'll talk about it in the
+> meeting.
+
+From inside a subprogram, a by-reference parameter (which this is) [as well as aliased
+parameters, and function results after mutating] is *less* local than the contents of
+the subprogram, but *more* local than anything outside of the subprogram. This follows
+from knowing that the actual parameter objects have to belong to some master outside of
+the subprogram (we just don't know which one) -- they don't belong to the master that
+is the execution of the subprogram itself. Since we don't know which one, and it could
+be very local (a single subprogram call, for instance), we have to treat the parameters
+as more local than anything else visible.
+
+I tried writing wording on this basis for aliased parameters, and it didn't work out well.
+Tucker eventually convinced me to give up and not bother as it really wasn't needed for
+anything. Other than this subpool check (not thought of at the time). That probably was
+more the fault of the author than the concept, although I can't be certain of that.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 20, 2011  2:05 PM
+
+> It's your fault, really. I was trying to figure out how you could
+> write a pool of Root_Storage_Pool'Class.
+
+The case I usually have in mind is "for T'Storage_Pool use X.all;", where X is of an
+access type whose designated type is Root_Storage_Pool'Class.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 20, 2011  4:02 PM
+
+This problem was covered in earlier versions of the subpool proposal, and the rule always
+required that any access type that used a pool-with-subpools be at the same level as the
+pool object.  But actually specifying the rule was always messy, and had these same
+upward-compatibility issues.  I believe we ended up defining it as a run-time check,
+but one that could usually be done at compile time.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 22, 2011  3:29 AM
+
+It is just a straight accessibility check (13.11.4(21/3) is the legality rule; 13.11.4(22/3)
+is the runtime part). Accessibility has the problem I noted, and how else would you define
+"at same level as the pool object"?? After all, inside of the subprogram, you can't *see*
+the level of the pool object, and the typical assumption is wrong.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 22, 2011  4:02 AM
+
+Assuming the worst is probably the way to do it.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, June 22, 2011  4:22 AM
+
+> It is just a straight accessibility check (13.11.4(21/3) is the
+> legality rule; 13.11.4(22/3) is the runtime part). Accessibility has
+> the problem I noted, and how else would you define "at same level as the pool object"??
+> After all, inside of the subprogram, you can't *see* the level of the
+> pool object, and the typical assumption is wrong.
+
+The problem is that this check/rule is sort of backwards from the normal
+accessibility checks/rules, so assuming that formal parameters are deeper than
+they are is not conservative, as it usually is.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 25, 2011  9:56 AM
+
+Put a comment line after Create_Subpool to separate the client part of this package from the pool implementor part, along with the description: “The following operations are intended for pool implementers:”.
+
+
+Add a Legality Rule after 13.11.4(22/3):
+
+For a formal parameter of Root_Storage_Pool'Class, the actual object shall not be a storage pool that supports subpools.  In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance o
f a generic unit.
+
+Add a Dynamic Semantics rule after 13.11.4(23/3):
+
+For a formal parameter of Root_Storage_Pool'Class, a check is made that the tag of the actual object does not identify a type that supports subpools. Program_Error is raised if this check fails.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, June 26, 2011  3:46 AM
+
+----------
+
+13.11.4(22) says:
+
+The accessibility level of a subpool access type shall not be statically deeper than that of the storage pool object.
+
+Add here:
+
+If the specified storage pool object is a storage pool that supports subpools, then the name that denotes the object shall not denote part of a formal parameter, nor shall it denote part of a dereference of a value of a non-library level general access ty
pe.
+
+
+13.11.4(23) says:
+
+When a subpool access type is frozen (see 13.14), a check is made that the accessibility level of the subpool access type is not deeper than that of the storage pool object. Program_Error is raised if this check fails.
+
+Add after 13.11(19):
+
+When an access type with a specified storage pool is frozen (see 13.14), if the name used to specify the storage pool object denotes part of a formal parameter or part of a dereference of a value of a non-library-level general access type, then a check is
 made that the tag of the storage pool object does not identify a storage pool that supports subpools (see 13.11.4).  Program_Error is raised if this check fails.
+
+   AARM Note: See 13.11.4 for an explanation of the restriction against use
+   of formal parameters and general access value dereferences.
+
+13.11.4(23a) says:
+
+Reason: This check (and its static counterpart) ensures that the type of the allocated objects exist at least as long as the storage pool object, so that the subpools are finalized (which finalizes any remaining allocated objects) before the type of the o
bjects ceases to exist. The access type itself (and the associated collection) will cease to exist before the storage pool ceases to exist.
+
+Add after that:
+
+We also disallow the use of formal parameters and dereferences of non-library-level general access types when specifying a storage pool object if it supports subpools, because the "apparent" accessibility level is potentially deeper than that of the under
lying object.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, June 26, 2011  5:39 AM
+
+Replace 13.11.4(23) with:
+
+When an access type with a specified storage pool is frozen (see 13.14), if the tag of the storage pool object identifies a storage pool that
+supports subpools, the following checks are made:
+
+* the name used to specify the storage pool object does not denote part of a
+formal parameter or part of a dereference of a value of a non-library-level general access type, and
+
+* the accessibility level of the subpool access type is not deeper than
+that of the storage pool object.
+
+Program_Error is raised if either of these checks fail.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent