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

--- ai05s/ai05-0116-1.txt	2008/11/21 02:09:24	1.2
+++ ai05s/ai05-0116-1.txt	2009/03/10 07:02:52	1.3
@@ -1,6 +1,8 @@
 !standard 13.3(29)                                             08-11-20  AI05-0116-1/02
 !standard 13.11(16)
 !class binding interpretation 08-10-16
+!status Amendment 201Z 09-03-09
+!status ARG Approved  8-0-1  09-02-21
 !status work item 08-10-16
 !status received 08-07-29
 !priority Medium
@@ -16,7 +18,7 @@
 
 The value passed to the Alignment parameter of Deallocate for an instance
 of Unchecked_Deallocation is the same as that passed to the corresponding
-Allocate call. This may require dynamic determination of this is for
+Allocate call. This may require dynamic determination if this is for
 an access-to-classwide type.
 
 !question
@@ -69,7 +71,7 @@
 as their parent (whether or not there's an Alignment clause on the extension), and
 all root tagged types must be maximally aligned by default.
 
-What is the intent?
+What is the intent? (The alignment depends on the tag.)
 
 !recommendation
 
@@ -84,20 +86,20 @@
 [Editor's Note: This is *not* recommended level of support, which generally only
 talks about what can be specified, not about values. This is similar to 13.3(41.1/2).]
 
-AARM Reason: An object should never be less aligned than its alignment, so for a
-classwide type T'Class, the alignment should be no greater than that of any type
-covered by T'Class. If the implementation only supports alignments that are required
-by the recommended level of support (and this is most likely), then the alignment of
-any covered type has to be the same or greater than that T -- which leaves the only
+AARM Reason: A tagged object should never be less aligned than the alignment of the type
+of its view, so for a classwide type T'Class, the alignment should be no greater than that
+of any type covered by T'Class. If the implementation only supports alignments that are
+required by the recommended level of support (and this is most likely), then the alignment
+of any covered type has to be the same or greater than that of T -- which leaves the only
 reasonable value of T'Class'Alignment being T'Alignment. Thus we suggest that, but
 don't require it in the unlikely case the implementation does support smaller alignments
 for covered types.
 
 
-Add before AARM 13.3(32.a/2):
+Add after AARM 13.3(32.a/2):
 
 AARM Implementation Note: An implementation that tries to support other alignments 
-for derived tagged types will need to allowed inherited subprograms to be passed
+for derived tagged types will need to allow inherited subprograms to be passed
 objects that are less aligned than expected by the parent subprogram and type.
 This is unlikely to work if alignment has any effect on code selection. Similar
 issues arise for untagged derived types whose parameters are passed by reference.
@@ -109,9 +111,9 @@
 passing T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements
 parameter indicates the number of storage elements to be allocated, and is
 no more than D'Max_Size_In_Storage_Elements, where D is the designated subtype.
-The Alignment parameter is D'Alignment{ if D is a specific type, and is the
-Alignment of the specific type identified by the tag of the object being created
-otherwise}. The result returned in the Storage_Address
+The Alignment parameter is D'Alignment{ if D is a specific type, and otherwise
+is the Alignment of the specific type identified by the tag of the object being
+created}. The result returned in the Storage_Address
 parameter is used by the allocator as the address of the allocated storage,
 which is a contiguous block of memory of Size_In_Storage_Elements storage
 elements. Any exception propagated by Allocate is propagated by the allocator. 
@@ -173,7 +175,35 @@
 language does not require such overhead because it does not allow such specification
 of alignments.
 
---!corrigendum 13.11(16)
+!corrigendum 13.3(29)
+
+@dinsb
+The recommended level of support for the Alignment attribute for subtypes is: 
+@dinst
+For any tagged specific subtype @i<S>, @i<S>'Class'Alignment should equal @i<S>'Alignment.
+
+!corrigendum 13.11(16)
+
+@drepl
+An @fa<allocator> of type T allocates storage from T's storage pool. If the storage pool
+is a user-defined object, then the storage is allocated by calling Allocate, passing
+T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements parameter indicates
+the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements,
+where D is the designated subtype. The Alignment parameter is D'Alignment. The result returned
+in the Storage_Address parameter is used by the @fa<allocator> as the address of the
+allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage
+elements. Any exception propagated by Allocate is propagated by the @fa<allocator>. 
+@dby
+An @fa<allocator> of type T allocates storage from T's storage pool. If the storage pool
+is a user-defined object, then the storage is allocated by calling Allocate, passing
+T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements parameter indicates
+the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements,
+where D is the designated subtype. The Alignment parameter is D'Alignment if D is
+a specific type, and otherwise is the alignment of the specific type identified by the
+tag of the object being created. The result returned
+in the Storage_Address parameter is used by the @fa<allocator> as the address of the
+allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage
+elements. Any exception propagated by Allocate is propagated by the @fa<allocator>. 
 
 
 !ACATS Test