CVS difference for ais/ai-00291.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00291.txt

--- ais/ai-00291.txt	2004/10/28 05:50:36	1.8
+++ ais/ai-00291.txt	2004/12/09 18:53:15	1.9
@@ -1,4 +1,16 @@
-!standard  4.09 (38)                                   04-10-05  AI95-00291/05
+!standard 13.01 (18.1/1)                                04-12-07  AI95-00291/06
+!standard 13.01 (21)
+!standard 13.01 (24)
+!standard 13.02 (06)
+!standard 13.03 (18)
+!standard 13.03 (22/1)
+!standard 13.03 (23)
+!standard 13.03 (24)
+!standard 13.03 (25)
+!standard 13.03 (26)
+!standard 13.03 (28)
+!standard 13.03 (43)
+!standard 13.03 (56)
 !class binding interpretation 02-03-26
 !status work item 03-09-17
 !status received 02-03-26
@@ -12,16 +24,14 @@
 The recommended level of support for representation items does not preclude
 maintaining the invariant that all objects of a given by-reference
 type and all aliased objects of any given type are consistently aligned and
-have a common representation (ignoring extra space at the end of a composite
-object).
+have a common representation.
 
 !question
 
 The recommended level of support for representation items should not
 preclude maintaining the invariant that all objects of a given by-reference
 type and all aliased objects of any given type are consistently aligned and
-have a common representation (ignoring extra space at the end of a composite
-object).
+have a common representation.
 
 There exist representation items which violate this rule (and which most
 implementations would therefore reasonably reject) but which are not excluded
@@ -49,37 +59,33 @@
 
     * An implementation need not support a nonconfirming representation item if
       it could cause an aliased object or an object of a by-reference type
-      to be allocated at a nonaddressable location or, if the alignment
+      to be allocated at a nonaddressable location or, when the alignment
       attribute of the subtype of such an object is nonzero, at an address
-      which is not an integral multiple of that alignment.
+      that is not an integral multiple of that alignment.
 
     * An implementation need not support a nonconfirming representation item
-      if it could cause an aliased object or an object whose type is
-      by-reference to have a size smaller than that which would have been
-      chosen by default.
+      if it could cause an aliased object, or an object whose type is
+      by-reference, to have a size other than that which would have been chosen
+      by default.
 
-    * An implementation need not support a nonconfirming representation item
-      if it could cause an aliased object of an elementary type to have a
-      size larger than that which would have been chosen by default.
-
     * An implementation need not support a nonconfirming subtype-specific
       representation item specifying an aspect of representation of an
       indefinite or abstract subtype.
 
     For purposes of these rules, the determination of whether a representation
     item applied to a type "could cause" an object to have some property
-    should be based solely on the properties of the type itself, not on any
-    available information about how the type is used. In particular, it should
-    be assumed that minimally aligned objects of this type are declared at
+    is based solely on the properties of the type itself, not on any
+    available information about how the type is used. In particular, it
+    presumes that minimally aligned objects of this type might be declared at
     some point.
 
 Insert after 13.2(6):
 
     If a packed type has a component which is not
     of a by-reference type and has no aliased part,
-    then that component of an object need not be allocated at
-    an addressable location whose address is an integral multiple of the
-    Alignment of the component's subtype.
+    then such a component need not be be aligned according
+    to the Alignment of the component's subtype; in particular
+    it need not be allocated on a storage element boundary.
 
 Delete 13.3(18) [text was moved to 13.1(24)]
 
@@ -148,7 +154,7 @@
     type T is array (1..32) of aliased Boolean;
     for T'Size use 32;
 
-; we just want to *allow* implementations to reject such beasts without
+We just want to *allow* implementations to reject such beasts without
 running afoul of C.2(2).
 
 Note that the term "object" includes the case of a component. Thus, for
@@ -176,21 +182,6 @@
 Note that the representation item need not be an alignment clause.
 It could be a Pack pragma, a Component_Size specification, a record
 representation clause, a size clause, etc.
-
-Note that we distinguish between elementary types and composite
-types. Allowing for extra space at the end of a composite object is not
-considered to impose a burden on implementations, even for
-aliased or by-reference types. This is particularly important for
-record types because there are no standard rules for choosing the
-size of a record subtype. For example, some implementations round
-up to a multiple of the alignment of the record subtype when determining
-the subtype size, while others do not, deferring the padding
-to the allocation of particular objects or arrays of such objects.
-
-We want to allow users to pad out the size of an external record
-object so as to allow for the expectations of a different compiler or
-a different language, even if other objects of the type are not
-always given this padded amount.
 
 We don't reiterate the allowed restriction on alignment and size
 for aliased and by-reference objects in each RM paragraph where it

Questions? Ask the ACAA Technical Agent