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

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

--- ai12s/ai12-0059-1.txt	2015/11/20 03:11:26	1.6
+++ ai12s/ai12-0059-1.txt	2015/11/20 04:07:47	1.7
@@ -1,4 +1,11 @@
-!standard 13.03 (58)                              15-10-17    AI12-0059-1/06
+!standard 4.9.1(2/3)                              15-11-19    AI12-0059-1/07
+!standard 13.1(14)
+!standard 13.1(23)
+!standard 13.3(9/1)
+!standard 13.3(50)
+!standard 13.3(51)
+!standard 13.3(52)
+!standard 13.3(58)
 !class Amendment 13-01-30
 !status work item 13-01-30
 !status received 12-09-21
@@ -70,12 +77,14 @@
 neither, and the nonconfirming values, if any, are the same,} and, for
 access subtypes, either both or neither exclude null.
 
+Add the following after 4.9.1(2/3):
+
     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 a previously statically matching subtype fail
     to match; it cannot make a match legal.
 
-    AARM Discussion: We include the case where both Object_Sizes are
+    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 a rule in
@@ -83,11 +92,14 @@
     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 ...").
+
+Modify 13.1(14):
 
-Modify 13.1(14 and 14.a/3):
-  If two subtypes statically match, then their subtype-specific aspects
-  ({for  example, }Size and Alignment) are the same.
+If two subtypes statically match, then their subtype-specific aspects
+({for  example, }Size and Alignment) are the same.
 
+Modify AARM 13.1(14.a/3):
+
    AARM Reason: This is necessary because we allow (for example)
    conversion between access types whose designated subtypes statically
    match. Note that most aspects (including the subtype-specific aspects
@@ -122,9 +134,10 @@
 
    {AARM Reason: We don't want to require that Size or Object_Size be
     supported on types that might have a representation not completely
-    specified at compile-time, or are represented discontiguously, or are
+    specified at compile time, or are represented discontiguously, or are
     represented differently for different constraints.}
 
+
 [Editor's note: The below wording is in the style of 13.3, which is where it
 will be placed in the Standard. As such, it does not mention aspect
 specifications, it only talks about the attribute. This is intended.]
@@ -133,6 +146,38 @@
 The following representation attributes are defined: Address, Alignment,
 Size, {Object_Size, }Storage_Size, and Component_Size.
 
+Change 13.3(50) to:
+
+If the Size of a subtype is nonconfirming and allows for efficient independent
+addressability (see 9.10) on the target architecture, then the Object_Size of
+the subtype should have the same value in the absence of an explicit
+specification of a different value.
+
+[Editor's note: I have "is nonconfirming" here (which is new) because we
+usually don't require confirming aspects to have any non-default effect.
+Without the "nonconfirming", this would have the effect of forcing a
+nonconfirming value of Object_Size for some subtypes.]
+
+Delete 13.3(51-52).
+
+[Editor's Note: This IA is effectively moved to the IA for the meaning of
+Object_Size.]
+
+Add after 13.3(52):
+
+    AARM Reason: We talk about the explicit specification of Object_Size so that
+    we have specified what happens if both Object_Size and Size
+    are specified incompatibly; we give priority to Object_Size. Note that the
+    value of Size no longer has any direct effect on the Size of objects; what
+    happens instead is that the value of Size can have an effect on the
+    value of Object_Size in the absence of a specification for Object_Size,
+    and it's the value of Object_Size that determines the size of an object.
+
+[Editor's note: Since all of this is Implementation Advice, compilers can
+ignore all of it anyway. For instance, we believe that GNAT currently ignores
+13.3(50-2) for non-first subtypes. Thus it's pointless to obsess about getting
+it perfect for every possible implementation.]
+
 Insert the following after 13.3(58):
 
 For every subtype S:
@@ -158,24 +203,6 @@
    restrictions on which subtypes allow specification of Object_Size (as
    with any representation attribute).
 
-[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
-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, constant or not.]
-
-[2nd Editor's note: 13.1(7/2) allows padding bits to be part of the Size of
-composite objects (including aliased composite objects). A compiler could
-have implicitly added padding bits to such an object and reported the Size with
-those bits. In order to implement Object_Size, such a compiler ought to
-change the reported Size for objects to not include the padding bits if the
-Oject_Size does not include them (it does NOT have to change anything about
-the allocation, since unused bits are always allowed). If the size of the
-object is explicitly specified, no change is needed.]
-
 Implementation Advice
 
 If S is a definite first subtype and S'Object_Size is not specified,
@@ -226,7 +253,7 @@
    Corresponding support is expected for modular integer subtypes,
    fixed point subtypes, and enumeration subtypes.
 
-  AARM Ramification: The intent is that a compiler needs support only those
+  AARM Ramification: The intent is that a compiler need support only those
   Object_Sizes that it might select for an integer type declaration.
 
  * If S is an array or record subtype with static constraints and S is not
@@ -236,43 +263,13 @@
    no smaller than S'Size, and that is no larger than that of the largest
    composite subtype supported by the implementation.
 
-  AARM Discussion: Any extra bits required this way will be trailing
-  padding bits. Unlike elementary objects, padding bits can be
-  considered part of composite objects.
+  AARM Discussion: Any extra bits required this way will be padding bits.
+  Unlike elementary objects, padding bits can be considered part of composite
+  objects.
 
  * If S is some other subtype, only confirming specifications of Object_Size
    need be supported.
 
-Change 13.3(50) to:
-
-If the Size of a subtype is nonconfirming and allows for efficient independent
-addressability (see 9.10) on the target architecture, then the Object_Size of
-the subtype should have the same value in the absence of an explicit
-specification of a different value.
-
-[Note on version /5: I have "is nonconfirming" here because we usually don't
-require confirming aspects to have any non-default effect. Without the
-"nonconfirming", this would have the effect of forcing a nonconfirming
-value of Object_Size for some subtypes. Both authors agree on this point.]
-
-Delete 13.3(51-52).
-
-[Editor's Note: This IA is effectively moved to the IA for the meaning of
-Object_Size.]
-
-    AARM Reason: We talk about the explicit specification of Object_Size so that
-    we have specified what happens if both Object_Size and Size
-    are specified incompatibly; we give priority to Object_Size. Note that the
-    value of Size no longer has any effect on the Size of objects; what
-    happens instead is that the value of Size can have an effect on the
-    value of Object_Size in the absence of a specification for Object_Size.
-
-[Editor's note: Since all of this is Implementation Advice, compilers can
-ignore all of it anyway. For instance, we believe that GNAT currently ignores
-13.3(50-2) for non-first subtypes. Thus it's pointless to obsess about getting
-it perfect for every possible implementation.]
-
-
 !discussion
 
 Object_Size covers the cases that are not specified by Size. Size is only
@@ -316,20 +313,34 @@
 
 ============================
 
+13.1(7/2) allows padding bits to be part of the Size of composite objects
+(including aliased composite objects). A compiler could have implicitly added
+padding bits to such an object and reported the Size with those bits. In order
+to implement Object_Size, such a compiler ought to change the reported Size
+for objects to not include the padding bits if the Object_Size does not include
+them (it does NOT have to change anything about the allocation, since unused
+bits are always allowed). If the size of the object is explicitly specified,
+no change is needed.
+
+============================
+
 Note that (Sub)type'Size is not a significant problem for composite types; the
 language there does not require bizarre values for 'Size. So a solution only
 really needs to apply to scalar types.
 
-An alternative (if 'Object_Size would become too incompatible with the existing
-implementation) would be to extend 'Component_Size to scalar types, with
-the meaning that is specifies the size to be used for components in the
+An alternative (if 'Object_Size had become too incompatible with the existing
+implementation) would have been to extend 'Component_Size to scalar types, with
+the meaning that it specified the size to be used for components in the
 absence of representation clauses. Note that the size of stand-alone objects
-is rarely relevant; the size of a subtype is usually an issue when
-it is used in components in a number of composite types (and giving
-representation clauses on all of them is painful). Doing so would eliminate
-the need to provide subtype specifiability for the aspect, and would ensure
-that there would be no conflicts with existing implementations. (They are not
-allowed to use a language-defined attribute in a different way.)
+is rarely relevant; the size of a subtype is usually an issue when it is used
+in components in a number of composite types (and giving representation
+clauses on all of them is painful). Doing so would have eliminated
+the need to provide subtype specifiability for the aspect, and would have
+ensured that there would be no conflicts with existing implementations. (They
+are not allowed to use a language-defined attribute in a different way.)
+We believe, however, that our definition of Object_Size does not cause
+problems for the existing implementation and that it is the most natural way
+to provide this functionality.
 
 !example
 

Questions? Ask the ACAA Technical Agent