CVS difference for ais/ai-00291.txt

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

--- ais/ai-00291.txt	2002/05/25 03:42:19	1.2
+++ ais/ai-00291.txt	2003/09/19 01:42:27	1.3
@@ -1,4 +1,4 @@
-!standard  4.09 (38)                                   02-04-19  AI95-00291/01
+!standard  4.09 (38)                                   02-09-17  AI95-00291/02
 !class binding interpretation 02-03-26
 !status received 02-03-26
 !qualifier Error
@@ -21,6 +21,123 @@
 intended? (No.)
 
 !recommendation
+
+!wording
+
+Replace 13.1(24) with
+
+    A representation item need not be supported if it could cause
+    an aliased object, a volatile 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 non-zero,
+    at an address which is not an integral multiple of that alignment.
+
+    A representation item need not be supported 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
+    unless that subtype is discriminated and unconstrained.
+
+    A representation item that specifies the default value for an aspect of
+    representation (i.e. the value that would have been chosen in the absence
+    of the representation item) is said to be *confirming*. A confirming
+    representation item should be supported.
+
+    A nonconfirming subtype-specific representation item specifying an aspect
+    of representation of an indefinite subtype need not be supported.
+
+Insert after 13.1(24)
+    NOTES
+
+    The determination of whether a representation item which applies 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 some point.
+
+Insert after 13.2(6):
+
+    If an object of a packed type has a component which is neither aliased nor
+    of a by-reference type, then that component need not be allocated at
+    an addressable location whose address is an integral multiple of the
+    Alignment of the component's subtype.
+
+In 13.2(8), delete
+
+     "; the implementation may, but need not, reorder components or
+     cross aligned word boundaries to improve the packing".
+
+Delete 13.3(18)
+
+Replace 13.3(23), sentence 1
+    "The address of an object that is allocated under control of the
+    implementation is an integral multiple of the Alignment of the
+    object (that is, the Address modulo the Alignment is zero)."
+  with
+     "<same as before> ... is zero), unless specified otherwise by
+     a representation item."
+
+Insert after 13.3(26)
+    An implementation need not support Alignments specified for a
+    derived tagged type which are not multiples of the Alignment
+    of the type's parent type. An implementation need not support
+    nonconfirming Alignments specified for a derived untagged
+    by-reference type.
+
+    An implementation need not support Alignments specified for
+    objects of a by-reference type or for objects of types containing
+    aliased or volatile subcomponents if the specified Alignment is not
+    a multiple of the Alignment of the object's subtype.
+
+In 13.3(43) replace
+    "A Size clause should be supported for an object if ..."
+with
+    "A Size clause should be supported for an object (excepting
+    aliased objects, volatile objects, and objects of by-reference types)
+    if ..."
+
+Insert after 13.3(56)
+    A nonconfirming size clause for the first subtype of a
+    derived untagged by-reference type need not be supported.
+
+In 13.5.1(19), replace
+    "A storage place should be supported" with "A storage place for
+    an unaliased nonvolatile component should be supported".
+
+Insert after 13.3(72):
+    An implementation need not support a nonconfirming Component_Size
+    clause if the array type has a by-reference, aliased, or volatile part.
+
+
+!Discussion
+We do not want to *require* that implementations reject problematic
+representation items such as
+
+    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
+running afoul of C.2(2).
+
+
+Note that the term "object" includes the case of a component. Thus, for
+example, the allowed non-support of a representation clause which could result
+in a misaligned object would imply permission to reject something like
+
+     type Rec1 is
+       record
+         F : aliased Integer;
+       end record;
+     for Rec1'Alignment use Integer'Alignment / 2;
+
+or
+     type Rec2 is
+       record
+          F : aliased Integer;
+       end record;
+     for Rec2 use
+       record
+          F at Integer'Alignment / 2 range 0 .. Integer'Size - 1;
+       end record;
 
 !wording
 

Questions? Ask the ACAA Technical Agent