CVS difference for ais/ai-00051.txt

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

--- ais/ai-00051.txt	2004/10/05 22:48:57	1.7
+++ ais/ai-00051.txt	2004/11/14 06:36:46	1.8
@@ -1,4 +1,4 @@
-!standard 13.03    (25)                               04-09-27  AI95-00051/13
+!standard 13.03    (25)                               04-11-08  AI95-00051/14
 !standard 13.03    (28)
 !standard 13.03    (30)
 !standard 13.03    (31)
@@ -35,22 +35,22 @@
 
 1. The implementation should support a Size or Alignment clause for an
    object if it specifies the same Size or Alignment that the
-   implementation would have chosen by default (i.e. a "confirming"
-   representation clause, as defined in AI 291).
+   implementation would have chosen by default (that is, a "confirming"
+   representation item, as defined in AI-291).
 
 2. For a signed integer type, the implementation need not support a
    Size/Alignment clause which specifies a value larger than the largest
    Size/Alignment value that would be chosen by the implementation
-   in the absence of a representation clause for any signed integer
+   in the absence of a attribute_definition_clause for any signed integer
    type. Corresponding advice applies for modular integer types,
    fixed point types, enumeration types, record types, and array types.
 
 3. Only confirming Size/Alignment clauses need be supported for floating point
    types, access types, protected types, and task types.
 
-4. Non-power-of-two alignments need not be supported.
+4. Alignments other than a power-of-two need not be supported.
 
-5. Confirming representation clauses have no semantic effect (this means
+5. Confirming representation items have no semantic effect (this means
    eliminating rules of the form "If attribute Xyz is specified, then" ...)
 
 !question
@@ -76,7 +76,7 @@
     "If the Alignment of a subtype is specified, then the Alignment of an object is
      at least as strict, unless the object's Alignment is also specified".
 with
-    "The Alignment of an object is at least as strict as the alignment
+    "The Alignment of an object is at least as strict as the Alignment
      of its subtype, unless the object's Alignment is specified".
 
 Replace 13.3(28) with
@@ -100,8 +100,9 @@
       an implementation need not support a nonconfirming Alignment clause.
 
     - An implementation need not support a nonconfirming Alignment clause
-      which could enable the creation of an elementary object which cannot be
-      easily loaded and stored by available machine instructions.
+      which could enable the creation of an object of an elementary type
+      which cannot be easily loaded and stored by available machine
+      instructions.
 
 Replace 13.3(42-3) with
     The recommended level of support for the Size attribute of objects is
@@ -117,7 +118,7 @@
 
     - An implementation need not support a Size clause for a signed
       integer type specifying a Size greater than the largest Size
-      value that would be chosen by default (i.e. in the absence of a
+      value that would be chosen by default (that is, in the absence of a
       Size clause) for any signed integer type. Corresponding advice
       applies for modular integer types, fixed point types, and enumeration
       types.
@@ -131,13 +132,13 @@
 The current recommended level of support, interpreted strictly, includes
 support for absurd constructs. This is the motivation for this AI.
 
-This AI depends on AI 291's definition of "confirming", as well as AI 291's
+This AI depends on AI-291's definition of "confirming", as well as AI-291's
 coverage of various cases involving aliased objects and by-reference types.
 
 !example
 
 This example shows some ramifications of the Recommended Level of Support.
-For each representation clause, we note whether it is covered by the
+For each representation item, we note whether it is covered by the
 Recommended Level of Support [Should be supported], whether it might be
 covered by the Recommended Level of Support (depending on the largest
 values allowed for integers) [Might be supported], or is not covered
@@ -172,9 +173,9 @@
 @xindent<Alignment may be specified for first subtypes and stand-alone objects
 via an @fa<attribute_definition_clause>; the expression of such a clause shall
 be static, and its value nonnegative. The Alignment of an object is at least as
-strict as the alignment of its subtype, unless the object's Alignment is
-specified. The Alignment of an object created by an allocator is that of the
-designated subtype.>
+strict as the Alignment of its subtype, unless the object's Alignment is
+specified. The Alignment of an object created by an @fa<allocator> is that of
+the designated subtype.>
 
 !corrigendum 13.3(28)
 
@@ -220,8 +221,8 @@
 greater than the maximum Alignment the implementation ever returns by default.>
 @dby
 @xbullet<An implementation need not support a nonconfirming Alignment clause
-which could enable the creation of an elementary object which cannot be easily
-loaded and stored by available machine instructions.>
+which could enable the creation of an object of an elementary type which cannot
+be easily loaded and stored by available machine instructions.>
 
 !corrigendum 13.3(42)
 
@@ -259,9 +260,9 @@
 @dinss
 @xbullet<An implementation need not support a Size clause for a signed integer
 type specifying a Size greater than the largest Size value that would be chosen
-by default (i.e. in the absence of a Size clause) for any signed integer type.
-Corresponding advice applies for modular integer types, fixed point types, and
-enumeration types.>
+by default (that is, in the absence of a Size clause) for any signed integer
+type. Corresponding advice applies for modular integer types, fixed point
+types, and enumeration types.>
 
 @xbullet<For floating point types, access types, record types, array types,
 protected types, and task types, an implementation need not support a

Questions? Ask the ACAA Technical Agent