CVS difference for ai05s/ai05-0224-1.txt
--- ai05s/ai05-0224-1.txt 2011/01/06 00:50:09 1.4
+++ ai05s/ai05-0224-1.txt 2011/01/17 04:29:03 1.5
@@ -1,4 +1,4 @@
-!standard D.7(7) 10-10-21 AI05-0224-1/00
+!standard D.7(7) 11-01-14 AI05-0224-1/01
!class binding interpretation 10-10-21
!status work item 10-10-21
!status received 10-06-07
@@ -8,6 +8,9 @@
!subject No_Task_Allocators and classwide returns
!summary
+Restrictions No_Task_Allocators and No_Protected_Type_Allocators can be enforced
+at runtime for allocators of class-wide types.
+
!question
How does the No_Task_Allocators restriction interact with a function that
@@ -23,15 +26,52 @@
Ptr : Ref := new Some_Limited_Type'Class'(F);
+!wording
+Add after D.7(7):
-!wording
+In the case of an initialized allocator of an access type whose designated type
+is class-wide and limited, a check is made that the specific type of the
+allocated object has no task subcomponents. Program_Error is raised if this
+check fails.
+
+Add after D.7(10.3/2):
+
+In the case of an initialized allocator of an access type whose designated type
+is class-wide and limited, a check is made that the specific type of the
+allocated object has no protected subcomponents. Program_Error is raised if this
+check fails.
+
+Add after D.7(19.1/2)
+
+The dynamic checks associated with the No_Task_Allocators and
+No_Protected_Type_Allocators described above are performed immediately before
+the point in the evaluation of the allocator where any allocated tasks would be
+activated. In the case of call to a function with a limited class-wide result
+type where the call is used to provide (directly, or through intervening
+function calls) the initial value for an initialized allocator, these checks may
+also be performed earlier, as part of the execution of a return statement.
+
+AARM note:
+If checks performed at return statements are performed in such a way that it is
+impossible for the check performed at the point of the allocator to fail, then
+that latter check may be eliminated (like any check whose success is
+guaranteed).
!discussion
+Attempting to enforce these restrictions at compile-time for class-wide types
+would prevent allocators for many types that have no task or protected type
+components. Enforcing the restrictions with a post-compilation check would be
+very complex (an error would only occur if a type T has task or protected
+components AND there is an allocator of a class-wide type that covers T; the
+allocator and the type T are likely to be in different units). Thus we adopt a
+runtime check.
!ACATS Test
+Create an ACATS like the example in the question, to verify that the checks are
+made.
!appendix
Questions? Ask the ACAA Technical Agent