CVS difference for ais/ai-00051.txt
--- ais/ai-00051.txt 1999/03/23 18:04:34 1.3
+++ ais/ai-00051.txt 1999/11/29 21:14:21 1.4
@@ -1,4 +1,4 @@
-!standard 13.03 (42) 99-03-22 AI95-00051/09
+!standard 13.03 (42) 99-11-29 AI95-00051/10
!class binding interpretation 95-06-25
!status work item 98-04-01
!status ARG Approved (subject to letter ballot) 8-0-2 97-11-14
@@ -12,7 +12,7 @@
!subject Size and Alignment Clauses for Objects
This AI addresses the requirements for which Size and Alignment clauses
must be supported for objects. For Size and Alignment of subtypes, see
@@ -67,9 +67,22 @@
4. For a non-aliased object, the implementation need not support an
-Alignment clause unless the Alignment evenly divides the size (in
-storage elements) of the object.
+Alignment clause unless:
+ - For a signed integer, the Alignment is less than or equal to that of
+ the largest signed integer type supported by the implementation.
+ - For a modular integer, the Alignment is less than or equal to that of
+ the largest modular type supported by the implementation.
+ - For an object of an enumerated type, the Alignment is less than or
+ equal to that of the largest signed integer type, or the largest
+ modular type, which ever is least aligned.
+For fixed point, floating point, access, and composite objects, the
+implementation need not support any Alignment other than what would be
+chosen by default.
In addition, the following Implementation Advice (not Recommended Level
of Support) is added:
@@ -79,7 +92,7 @@
object. If the view is constrained, the Size should reflect the current
size of the object, given its current discriminant values.
First question: The recommended level of support for the Size attribute
of an object (in RM-13.3(42,43)) implies that the following should be
@@ -111,13 +124,15 @@
size (perhaps 4*8) or the maximum size (perhaps 104*8)? The RM does not
answer this question.
+To Be Determined.
@@ -220,6 +235,62 @@
the object. For scalars, however, all bits in the representation of the
object should be set to some meaningful value.
+Similar reasoning applies to Alignment clauses for non-aliased objects.
+It seems unreasonable to require arbitrary values for discrete types. Values
+already supported for the class make sense, since the implementation already
+knows how to do such alignments. But requiring additional alignments simply
+add to the implementation burden. There may be hardware requirements on the
+alignment of an integer. For instance, some machines require 32-bit integers
+to be 32-bit aligned. An implementation for such hardware should not be
+required to support 8-bit aligned 32-bit integers. (* Oops: The rules as
+written require mis-aligned integers. Is this a bug?? *) Similarly, there may
+be hardware requirements on the alignment of fixed point, floating point, and
+access types, so we place no requirements other than to support "confirming"
+Alignment clauses. For composite objects, it might be an implementation burden
+to require arbitrary alignments (even within those required by the language),
+as there may be stricter requirements on the component subtypes or on the
+type as a whole. Again, consider the example of implementing small packed
+arrays of Booleans in the same manner as modular types. If there exist
+Alignments for modular types that are not supported, then these Alignments
+can't be supported for such packed arrays.
+Relevant wording from the RM follows:
+29 The recommended level of support for the Alignment attribute for
+ 30 An implementation should support specified Alignments that are
+ factors and multiples of the number of storage elements per word,
+ subject to the following:
+ 31 An implementation need not support specified Alignments for
+ combinations of Sizes and Alignments that cannot be easily loaded
+ and stored by available machine instructions.
+ 32 An implementation need not support specified Alignments that are
+ greater than the maximum Alignment the implementation ever
+ returns by default.
+33 The recommended level of support for the Alignment attribute for objects
+ 34 Same as above, for subtypes, but in addition:
+ 35 For stand-alone library-level objects of statically constrained
+ subtypes, the implementation should support all Alignments
+ supported by the target linker. For example, page alignment is
+ likely to be supported for such objects, but not for subtypes.
+These recommendations are hard requirements for implementations that
+support the Systems Programming Annex, by C.2(2) (see above)
+These requirements are both vague, and possibly require implementations to
+support non-natural alignments. The vague requirements cannot be depended on
+by users. They are replaced by this AI (for objects) and by AI-00109 (for
Second question: In the example, X'Size should be the max size. Here's
@@ -285,7 +356,7 @@
by the language in these cases anyway. A hard requirement is uncalled
for in this case (even for the SP Annex).
Questions? Ask the ACAA Technical Agent