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

--- ai05s/ai05-0116-1.txt	2008/10/17 04:14:33	1.1
+++ ai05s/ai05-0116-1.txt	2008/11/21 02:09:24	1.2
@@ -1,4 +1,5 @@
-!standard 13.11(16)                                           08-10-16  AI05-0116-1/01
+!standard 13.3(29)                                             08-11-20  AI05-0116-1/02
+!standard 13.11(16)
 !class binding interpretation 08-10-16
 !status work item 08-10-16
 !status received 08-07-29
@@ -9,8 +10,9 @@
 
 !summary
 
-T'Class'Alignment of a class-wide type must
-be no greater than the 'Alignment of any type covered by T'Class.
+For an implementation, T'Class'Alignment of a class-wide type must
+be no greater than the 'Alignment of any type covered by T'Class. We
+recommend that it always be T'Alignment.
 
 The value passed to the Alignment parameter of Deallocate for an instance
 of Unchecked_Deallocation is the same as that passed to the corresponding
@@ -19,9 +21,9 @@
 
 !question
 
-Must T'Alignment be maximal for all tagged types (by default)?
-("Maximally aligned" = largest natural alignment on the machine, i.e. max chosen by
-default for any type.)
+Must T'Alignment be maximal for all tagged types (by default)? (No.)
+("Maximally aligned" = largest natural alignment on the machine, that is, the
+maximum chosen by default for any type.)
 
 13.11(16) requires "new" to pass D'Alignment to Allocate, where D is the designated
 subtype, and 13.11.2(9/2) requires this same value to be passed to Deallocate.
@@ -75,6 +77,31 @@
 
 !wording
 
+Add before 13.3(29):
+
+For any tagged specific subtype S, S'Class'Alignment should equal S'Alignment.
+
+[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
+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):
+
+AARM Implementation Note: An implementation that tries to support other alignments 
+for derived tagged types will need to allowed 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.
+
 Modify 13.11(16):
 
 An allocator of type T allocates storage from T's storage pool. If the storage
@@ -82,9 +109,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 S'Alignment
-where S is the type determined by the subtype_indication or qualified_expression
-of the allocator otherwise}. The result returned in the Storage_Address
+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
 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. 
@@ -131,7 +158,7 @@
 example:
 
     X : Ref_T1 := new T2; -- pass Alignment => T1'Class'Alignment (4) to Allocate
-    Free (Y); -- pass Alignment => T2'Alignment (8) to Deallocate?!
+    Free (X); -- pass Alignment => T2'Alignment (8) to Deallocate?!
 
 But this is clearly wrong: we surely don't want to allocate an object with an
 alignment of 8 at an alignment of 4. The problem is that the wording of 13.11(16)
@@ -140,10 +167,11 @@
 to use the alignment of the allocated object if the designated subtype is classwide.
 
 Note that an implementation will not want to allow the specification of
-alignments for all subtypes (not just tagged ones), because that would require using
-similar techinques for all subtypes, and thus would add runtime overhead in order
-to determine the proper alignment to pass to Deallocate. The language does not
-require such overhead because it does not allow such specification of alignments.
+alignments for any non-first subtypes (not just tagged ones), because that would
+require using similar techinques for all subtypes, and thus would add runtime
+overhead in order to determine the proper alignment to pass to Deallocate. The
+language does not require such overhead because it does not allow such specification
+of alignments.
 
 --!corrigendum 13.11(16)