CVS difference for ai12s/ai12-0240-2.txt

--- ai12s/ai12-0240-2.txt	2018/12/12 02:49:40	1.2
+++ ai12s/ai12-0240-2.txt	2018/12/14 08:31:30	1.3
@@ -94,9 +94,10 @@
 split into two categories: \managed kinds\ and \unmanaged kinds\. A managed 
 kind of access object is subject to a number of compile-time and runtime rules
 that prevent various kinds of errors, including dangling references and 
-storage leaks. In contrast, a unmanaged kind of object is only subject to the 
+storage leaks. Allocations and deallocations only are allowed for
+managed kinds. In contrast, a unmanaged kind of object is only subject to the 
 normal rules for access types; it is useful when separate reference 
-abstractions are needed.
+abstractions are needed. 
 
 For most purposes, objects allocated for a fenced access type can be considered 
 part of their ultimate owner object, rather than the pool from which they are 
@@ -141,6 +142,24 @@
 
    AARM Reason: The restriction to pool-specific types makes most conversions
    from other access types illegal, even if the designated types are the same.
+
+The global specification of each ultimate owner type shall cover the Allocate 
+and Deallocate operations of the type of the storage pool associated with the
+fenced access type.
+
+   AARM Reason: For clients, the allocation and deallocation of objects
+   of the fenced access type should look like part of the operations for
+   the ultimate owner type. Any global references caused by those operations
+   need to be reflected in the use of the type. Deallocation will 
+   automatically happen during the finalization of the type; allocation
+   most likely will occur during initialization of the object.
+
+[Author's note: Is this enough? A deallocation can appear almost anywhere,
+as they're automatically called by assignment and finalization. OTOH, the
+6.1.2 rule is very vague and can be construed to cover virtually anything.
+(There is an implicit call to Allocate and Deallocate in any explicitly
+written subprograms.) These obscure cases will almost certainly have to be 
+tested by ACATS tests lest implementers be unaware of them.]
 
 No type shall be derived from a fenced access type.
 A fenced access type shall only match a formal access type which is itself