CVS difference for ai12s/ai12-0059-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0059-1.txt

--- ai12s/ai12-0059-1.txt	2015/01/23 02:24:52	1.3
+++ ai12s/ai12-0059-1.txt	2015/10/03 02:21:54	1.4
@@ -1,4 +1,4 @@
-!standard 13.03 (58)                              15-01-22    AI12-0059-1/03
+!standard 13.03 (58)                              15-10-02    AI12-0059-1/04
 !class Amendment 13-01-30
 !status work item 13-01-30
 !status received 12-09-21
@@ -35,7 +35,7 @@
 Since 'Size for scalar types represents the size of a value of the type, it
 in general is *not* the size of an object of the type. Thus, specifying the
 size of a (sub)type causes a number of unusual effects (such as the size
-being forgotten for some derviations).
+being forgotten for some derivations).
 
 The rules for (Sub)type'Size mean that it specifies the minimum size of a
 packed component. That's a pretty useless thing to specify (why would you want
@@ -47,7 +47,7 @@
 and it just requires that all values can be stored. So a compiler can completely
 ignore Size when a representation aspect other than Pack applies to a component;
 and since the 'Size is rarely defined to be a whole number of storage elements,
-it is essentially ignored for components that don't have a representation item.)
+it is essentially ignored for components that don't have a representation item.
 
 What we really want to specify is the size of a component or stand-alone object
 when there is no representation clauses given for the object: meaning no Pack,
@@ -66,18 +66,18 @@
 specifications, it only talks about the attribute. This is intended.]
 
 Add Object_Size to 13.3(9/1):
-The following representation attributes are defined, Address, Alignment,
+The following representation attributes are defined: Address, Alignment,
 Size, Object_Size, Storage_Size, and Component_Size.
 
 Insert the following after 13.3(58):
 
 For every subtype S:
 
-S'Object_Size	If S is definite and not inherently limited, denotes the
+S'Object_Size	If S is definite, is zero or denotes the
 size (in bits) that the implementation would choose for a stand-alone
 aliased object of subtype S. If S is inherently limited or indefinite, the
 meaning is implementation-defined. The value of this attribute is of the
-type universal_integer. The Object_Size of a subtype is at
+type universal_integer. The Object_Size of a subtype is zero or is at
 least as large as the Size of the subtype. Object_Size may be specified via
 an attribute_definition_clause; the expression of such a clause shall be static
 and its value nonnegative. If Object_Size is nonzero, all aliased objects
@@ -93,29 +93,29 @@
    AARM Discussion:
    We allow the size of zero so that implementations can be free to use
    whatever techniques it wants for allocating objects. That's especially true
-   for when following the Implementation Advice below.
+   when following the Implementation Advice below.
 
-[Editor's note: The Pittsburg meeting asked that this be changed to "aliased
+[Editor's note: The Pittsburgh meeting asked that this be changed to "aliased
 variable", because "one can imagine constants taking advantage of discriminants
 not changing." That's true for nonaliased constants, but an aliased
 constant can be used as a target of an access-to-constant, as can an
-access-to-variable. If the representations differ, there would be no way to
+aliased variable. If the representations differ, there would be no way to
 determine what to do when reading the object, especially when copying the
 entire object. (Reading bits not part of the object is not acceptable.)
-All aliased objects have to have the same representation, period.]
+All aliased objects have to have the same representation, constant or not.]
 
 Implementation Requirements
 
-If S1 and S2 are two subtypes that would statically match if S1'Object_Size =
-S2'Object_Size, then S1'Object_Size shall be the same as S2'Object_Size if
-Object_Size is not specified for either S1 or S2.
-
-    AARM Reason: This is necessary so that the definition of Object_Size is not
-    incompatible with earlier versions of Ada. Note that this rule applies
-    even to the implementation-defined value of Object_Size when it is not
-    specified. That's need because Object_Size is never inherited for a
-    subtype, it is independently determined for every subtype.
+If S1 and S2 are two subtypes that statically match, then S1'Object_Size shall
+be the same as S2'Object_Size.
 
+    AARM Reason: This is necessary so that the addition of Object_Size does
+    not cause incompatibilities in existing Ada code that does not use
+    Object_Size. Note that this rule applies even to the implementation-defined
+    value of Object_Size when it is not specified. That's needed because
+    Object_Size is never inherited for a subtype, it is independently
+    determined for every subtype.
+
 Implementation Advice
 
 If S is a definite first subtype and S'Object_Size is not specified,
@@ -201,12 +201,22 @@
 A subtype statically matches another subtype of the same type if they have
 statically matching constraints, all predicate specifications that apply to
 them come from the same declarations, {their Object_Sizes (see 13.3) are the
-same,} and, for access subtypes, either both or neither exclude null. 
+same if either is nonconforming,} and, for access subtypes, either both or
+neither exclude null. 
 
     AARM Ramification: If one of the subtypes is not yet frozen, an
     implementation may have to repeat the check when the subtypes are both
     frozen. This can only make to previously statically matching subtype fail
     to match; it cannot make a match legal.
+
+    AARM Discussion: We exclude the case where both Object_Sizes are
+    confirming so that we don't introduce an incompatibility for existing
+    Ada code. But practically the implementation can simply check that
+    the Object_Size values are the same, as we have an Implementation
+    Requirement that the Object_Size values are always the same for
+    statically matching subtypes. We wrote the rules this way to avoid
+    having wording that appeared to require predicting the future ("would
+    statically match if ...").
 
 Add Object_Size to 13.1(23):
 

Questions? Ask the ACAA Technical Agent