CVS difference for ais/ai-00051.txt

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

--- ais/ai-00051.txt	2004/04/30 02:35:36	1.5
+++ ais/ai-00051.txt	2004/08/31 23:06:00	1.6
@@ -1,4 +1,4 @@
-!standard 13.03    (42)                               04-04-08  AI95-00051/11
+!standard 13.03    (42)                               04-08-31  AI95-00051/12
 !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
@@ -30,10 +30,10 @@
 
 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 by default
-   (i.e. in the absence of a representation clause) for any signed integer
-   type. Similarly for modular integer types, fixed point types, enumeration
-   types, record types, and array types.
+   Size/Alignment value that would be chosen by the implementation
+   in the absence of a representation 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.
@@ -81,8 +81,8 @@
 
     - An implementation need not support an Alignment clause for a signed
       integer type specifying an Alignment greater than the largest Alignment
-      value that would be chosen by default (i.e. in the absence of an
-      Alignment clause) for any signed integer type. Similarly for
+      value that would be chosen by default by the implementation
+      for any signed integer type. Corresponding advice applies for
       modular integer types, fixed point types, enumeration types, record
       types, and array types.
 
@@ -90,8 +90,8 @@
       an implementation need not support a nonconfirming Alignment clause.
 
     - An implementation need not support a nonconfirming Alignment clause
-      which cannot be implemented efficiently using the available machine
-      instructions.
+      which could enable the creation of an elementary object 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
@@ -107,28 +107,21 @@
 
     - 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 an
-      Size clause) for any signed integer type. Similarly for
-      modular integer types, fixed point types, and enumeration types,
-      record types, and array types.
+      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, enumeration
+      types, record types, and array types.
 
     - For floating point types, access types, protected types, and task types,
       an implementation need not support a nonconfirming Size clause.
 
 !discussion
 
+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
 coverage of various cases involving aliased objects and by-reference types.
-
-Are the sentences beginning with "Similarly for" in 13.3(30-32) and 13.3(56)
-ok, or would something like "Similar advice applies for" be better?
-
-This AI does not address questions about the meaning of the Size attribute
-(e.g. the Size attribute of an unconstrained object of a discriminated type).
-Is there any need to explicitly state that this is implementation dependent?
-
-Is it ok to require support for nonconfirming Size and Alignment clauses
-for fixed point subtypes and objects?
 
 !example
 

Questions? Ask the ACAA Technical Agent