CVS difference for ais/ai-00291.txt

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

--- ais/ai-00291.txt	2004/10/04 23:53:02	1.7
+++ ais/ai-00291.txt	2004/10/28 05:50:36	1.8
@@ -1,4 +1,4 @@
-!standard  4.09 (38)                                   04-10-04  AI95-00291/04
+!standard  4.09 (38)                                   04-10-05  AI95-00291/05
 !class binding interpretation 02-03-26
 !status work item 03-09-17
 !status received 02-03-26
@@ -12,14 +12,16 @@
 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.
+have a common representation (ignoring extra space at the end of a composite
+object).
 
 !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.
+have a common representation (ignoring extra space at the end of a composite
+object).
 
 There exist representation items which violate this rule (and which most
 implementations would therefore reasonably reject) but which are not excluded
@@ -43,22 +45,26 @@
     A confirming representation item should be supported.
 
 Replace bulleted-list item 13.1(24) with the following (formatted as
-3 bulleted-list items and then a paragraph following the bulleted list):
+4 bulleted-list items and then a paragraph following the bulleted list):
 
-    *  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
-       attribute of the subtype of such an object is nonzero, at an address
-       which 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 different size than some other such object of the
-       same definite subtype.
-
-    *  An implementation need not support a nonconfirming subtype-specific
-       representation item specifying an aspect of representation of an
-       indefinite or abstract subtype.
+    * 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
+      attribute of the subtype of such an object is nonzero, at an address
+      which 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.
+
+    * 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
@@ -134,15 +140,6 @@
     A nonconfirming size clause for the first subtype of a
     derived untagged by-reference type need not be supported.
 
-Insert after 13.3(72):
-    An implementation need not support a nonconfirming Component_Size
-    clause if the array type has an aliased part.
-
-In 13.5.1(19), replace
-    "A storage place should be supported" with "A storage place for
-    an unaliased component should be supported".
-
-
 !discussion
 
 We do not want to *require* that implementations reject problematic
@@ -179,6 +176,27 @@
 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
+might apply. Implementations can refer to the new overarching
+permission to justify the restriction in any given compiler error
+message.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent