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

Differences between 1.4 and version 1.5
Log of other versions for file 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