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

--- ai05s/ai05-0190-1.txt	2011/05/19 04:48:21	1.17
+++ ai05s/ai05-0190-1.txt	2011/06/08 05:13:53	1.18
@@ -1,7 +1,13 @@
-!standard 13.11.3(0)                                11-05-18  AI05-0190-1/12
-!standard 7.6.1(11/3)
-!standard H.4(8.1/3)
+!standard 13.11.3(2)                                11-06-03  AI05-0190-1/13
+!standard 13.11.3(3)
+!standard 13.11.3(4)
+!standard 13.11.3(5)
+!standard 13.11.3(6)
+!standard 13.11.3(8)
+!standard 7.6.1(11/2)
+!standard H.4(8/1)
 !class amendment 09-11-03
+!status Amendment 2012 11-06-03
 !status ARG Approved (by Letter Ballot) 9-1-1  11-05-16
 !status work item 09-11-03
 !status received 09-11-03
@@ -72,10 +78,11 @@
 objects are finalized. For multiple collections declared at the same place, we
 do not define the order of their implicit declarations.
 
-Remove the AARM notes 3.3.2(38.i), 3.10(26.b), 13.11(43.b) as they talk about
+Remove the AARM notes 3.4(38.i), 3.10(26.b), 13.11(43.b) as they talk about
 the Ada 83 definition of "collection" -- which would be just confusing now.
 
-Renumber section 13.11.3, "Pragma Controlled" to be 13.11.4.
+Renumber section 13.11.3, "Pragma Controlled" to be 13.11.4. [Editor's note:
+it was removed by AI05-0229-1.]
 Add a new section:
 
 13.11.3 Default Storage Pools
@@ -111,11 +118,13 @@
 by the *storage_pool*_name, except within the immediate scope of a later pragma
 Default_Storage_Pool. Redundant[Thus, an inner pragma overrides an outer one.]
 
-A pragma Default_Storage_Pool shall not be used as a configuration pragma within
-the immediate scope of another such pragma.
+A pragma Default_Storage_Pool shall not be used as a configuration pragma
+that applies to a compilation unit that is within the immediate scope of
+another such pragma.
 
-    AARM Rationale: This is to prevent confusion in cases like this:
 
+    AARM Reason: This is to prevent confusion in cases like this:
+
         package Parent is
             pragma Default_Storage_Pool(...);
             ...
@@ -259,6 +268,149 @@
 The Default_Storage_Pool ensures that type Rec_Ptr and the anonymous type of
 Link share the same pool.
 
+!corrigendum 7.6.1(11/2)
+
+@drepl
+The order in which the finalization of a master performs finalization of
+objects is as follows: Objects created by declarations in the master are
+finalized in the reverse order of their creation. For objects that were
+created by @fa<allocator>s for an access type whose ultimate ancestor is
+declared in the master, this rule is applied as though each such object that
+still exists had been created in an arbitrary order at the first freezing
+point (see 13.14) of the ultimate ancestor type; the finalization of these
+objects is called the @i<finalization of the collection>.
+After the finalization of a master is complete, the objects finalized as part
+of its finalization cease to @i<exist>, as do any types and subtypes defined
+and created within the master.
+@dby
+The finalization of a master performs finalization of objects created by
+declarations in the master in the reverse order of their creation.
+After the finalization of a master is complete, the objects finalized as part of
+its finalization cease to exist, as do any types and subtypes defined and created
+within the master.
+
+Each nonderived access type @i<T> has an associated @i<collection>, which is the set
+of objects created by @fa<allocator>s of @i<T>, or of types derived from @i<T>.
+Unchecked_Deallocation removes an object from its collection. Finalization of a
+collection consists of finalization of each object in the collection, in an
+arbitrary order. The collection of an access type is an object implicitly
+declared at the following place:
+
+@xbullet<For a named access type, the first freezing point (see 13.14) of
+the type.>
+
+@xbullet<For the type of an access parameter, the call that contains the
+@fa<allocator>.>
+
+@xbullet<For the type of an access result, within the master of the call
+(see 3.10.2).>
+
+@xbullet<For any other anonymous access type, the first freezing point of
+the innermost enclosing declaration.>
+
+!corrigendum 13.11.3(2)
+
+@drepl
+@xindent<The form of a pragma Controlled is as follows:>
+@dby
+@xindent<The form of a pragma Default_Storage_Pool is as follows:>
+
+!corrigendum 13.11.3(3)
+
+@drepl
+@xindent<@b<pragma> Controlled(@i<first_subtype_>@fa<local_name>)>
+@dby
+@xindent<@b<pragma> Default_Storage_Pool(@fa<storage_pool_indicator>);>
+
+@xindent<@fa<storage_pool_indicator> ::= @i<storage_pool_>@fa<name> | @b<null>>
+
+A @fa<pragma> Default_Storage_Pool is allowed immediately within the visible part of
+a @fa<package_specification>, immediately within a @fa<declarative_part>, or as a
+configuration pragma.
+
+@s8<@i<Name Resolution Rules>>
+
+The @i<storage_pool_>@fa<name> is expected to be of type Root_Storage_Pool'Class.
+
+!corrigendum 13.11.3(4)
+
+@drepl
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Controlled shall denote a
+non-derived access subtype.
+@dby
+The @i<storage_pool_>@fa<name> shall denote a variable.
+
+If the @fa<pragma> is used as a configuration pragma, the @fa<storage_pool_indicator>
+shall be @b<null>, and it defines the @i<default pool> to be @b<null> within all
+applicable compilation units (see 10.1.5), except within the immediate scope of
+another @fa<pragma> Default_Storage_Pool. Otherwise, the pragma occurs
+immediately within a sequence of declarations, and it defines the default pool
+within the immediate scope of the pragma to be either @b<null> or the pool denoted
+by the @i<storage_pool_>@fa<name>, except within the immediate scope of a later pragma
+Default_Storage_Pool. Thus, an inner pragma overrides an outer one.
+
+A @fa<pragma> Default_Storage_Pool shall not be used as a configuration pragma
+that applies to a compilation unit that is within the immediate scope of
+another such pragma.
+
+!corrigendum 13.11.3(5)
+
+@drepl
+A @fa<pragma> Controlled is a representation pragma that specifies the controlled
+aspect of representation.
+@dby
+The pragma applies to all nonderived access types declared in the places
+defined above, unless Storage_Pool or Storage_Size is specified for the type:
+
+@xbullet<If the default pool is @b<null>, the Storage_Size attribute is defined
+by the language to be zero. Therefore, an @fa<allocator> for such a type is
+illegal.>
+
+@xbullet<If the default pool is nonnull, the Storage_Pool attribute is that
+pool.>
+
+@xbullet<Otherwise, there is no default pool; the standard storage
+pool is used for the type as described in 13.11.>
+
+!corrigendum 13.11.3(6)
+
+@drepl
+@i<Garbage collection> is a process that automatically reclaims storage, or moves
+objects to a different address, while the objects still exist.
+@dby
+The language-defined aspect Default_Storage_Pool may be used to define the
+default pool for access types within an instance. The expected type for the
+Default_Storage_Pool aspect is Root_Storage_Pool'Class. The @fa<aspect_definition>
+must be a name that denotes a variable. This aspect overrides any
+Default_Storage_Pool pragma that might apply to the generic unit.
+
+!corrigendum 13.11.3(8)
+
+@drepl
+An implementation need not support garbage collection, in which case, a pragma Controlled
+has no effect.
+@dby
+An object created by an @fa<allocator> that is passed as the actual parameter to an
+access parameter may be allocated on the stack, and automatically reclaimed,
+regardless of the default pool.
+
+@s9<NOTES@hr
+10 Default_Storage_Pool may be used with restrictions No_Coextensions and
+No_Access_Parameter_Allocators (see H.4) to ensure that all @fa<allocator>s use the
+default pool.>
+
+!corrigendum H.4(8/1)
+
+@dinsa
+@xhang<@xterm<No_Local_Allocators>@fa<Allocator>s are prohibited in subprograms,
+generic subprograms, tasks, and entry bodies.>
+@dinss
+@xhang<@xterm<No_Coextensions>There are no coextensions. See 3.10.2.>
+
+@xhang<@xterm<No_Access_Parameter_Allocators>@fa<Allocator>s are not permitted as the
+actual parameter to an access parameter. See 6.1.>
+
+
 !ACATS test
 
 ACATS B and C tests are needed.
@@ -3578,6 +3730,20 @@
 >      for each access-to-object type."
 
 Probably a reference to 13.11 would be best.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 3, 2011  2:31 PM
+
+> I have no idea. Bob??
+
+Tucker's rewording is fine with me.  Except he misuses "which".  ;-)
+So:
+
+    A pragma Default_Storage_Pool shall not be used as a configuration pragma
+    that applies to a compilation unit that is within the immediate scope of
+    another such pragma.
 
 ****************************************************************