CVS difference for ai05s/ai05-0012-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0012-1.txt

--- ai05s/ai05-0012-1.txt	2006/04/20 05:30:39	1.2
+++ ai05s/ai05-0012-1.txt	2007/05/24 01:17:55	1.3
@@ -1,8 +1,7 @@
-!standard 13.1(24/2)                                      06-03-31    AI05-0012-1/01
-!standard 13.1(25/2)
-!standard 13.1(26/2)
-!standard 13.2(6.1/2)
+!standard 13.2(6.1/2)                                      07-05-20    AI05-0012-1/02
+!standard 13.2(7)
 !standard C.6(10)
+!standard C.6(11)
 !standard C.6(21)
 !class binding interpretation 06-03-31
 !status work item 06-03-31
@@ -14,107 +13,98 @@
 
 !summary
 
-The recommended level of support is adjusted to say that it is not required to
-support a non-confirming representation clause that would cause an
-atomic object to have a size or alignment different than the default
-size or alignment for that object.
+This action item resolves the difference in recommended level of support
+for atomic and volatile objects by making the alignment implementation
+advice recommended support and adding a rejection statement for those
+array objects that are packed to a different alignment than that of
+the component's subtype.
 
-The components of an object covered by an Atomic_Components pragma are always
-independent.
-
 !question
 
 The Recommended Level of Support implies that it is required to support pragma
 Pack on types that have Atomic_Components, even to the bit level. Is this the
-intent? (No.) Should it be required to 
+intent? (No.) 
 
 !recommendation
 
-13.1(24-26) needs to cover atomic objects as well.
+Resolve the difference by eliminating C.6 (21) and changing 13.2 (6.1/2)
+to be a recommended level of support where by-reference, aliased, atomic
+and volatile objects must be aligned according to subtype.
 
-!wording
+Change 13.2(9) to reject packed arrays that require independent addressability,
+but are packed to a different or no alignment.
 
-Insert "or atomic" into "aliased object" in 13.1(24-26).
+In C.6(10-11), add "and Independent" after indivisible.
 
-Replace 13.2(6.1/2) with:
+Delete C.6 (21) as it is no longer required.
 
-    The component of a packed type need not be aligned according to the
-    Alignment of its subtype; in particular it need not be allocated on
-    a storage element boundary.
+!wording
 
-Add "and independent" after "indivisible" in C.6(10).
+13.2 (6.1/2) is moved after 13.2 (7) and changed to:
 
-Delete C.6(21).
+For a packed type that has a component that is of a by-reference type,
+aliased, volatile, or atomic, the component shall be aligned according to
+the alignment of its subtype; in particular it shall be aligned on a
+storage element boundary.
 
-!discussion
+13.2 (9) append:
 
-13.2(6.1/2) conflicts with the Recommended Level of Support. Changing the
-Recommended Level of Support was rejected as that could cause the representation
-of types with representation clauses to change silently when "aliased" is added
-or deleted. The pragma Pack can be rejected anyway based on 13.1(24-26); there is
-no reason duplicate those permissions here.
-
-Similarly, C.6(21) conflicts with the Recommended Level of Support. We don't want
-the representation of a packed array of Boolean to depend on other keywords
-(like aliased) or pragmas that apply to the type. (That could cause silent
-representation changes during maintenance.)
+If the array component is required to be aligned according to its subtype
+and the results of packing are not so aligned, pragma pack should be rejected.
 
-This change makes C.6(11) redundant. [Should it be deleted? - RLB]
+C.6 (10-11)
 
-[Potentially, the change to C.6(10) could be removed if the resolution of AI05-0009
-covers it. - RLB.]
+Add "and independent" after indivisible.
 
-!corrigendum 13.1(24/2)
+C.6 (21, AARM 21.a) Delete.
 
-@drepl
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased object or an object of a by-reference type to be
-allocated at a nonaddressable location or, when the alignment attribute of the
-subtype of such an object is nonzero, at an address that is not an integral
-multiple of that alignment.>
-@dby
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased or atomic (see C.7) object or an object of a by-reference
-type to be
-allocated at a nonaddressable location or, when the alignment attribute of the
-subtype of such an object is nonzero, at an address that is not an integral
-multiple of that alignment.>
+!discussion
 
-!corrigendum 13.1(25/2)
+Addition of atomic (and volatile) to 13.1 (24-26) was discarded because
+neither pragma is confirming.
 
-@drepl
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased object of an elementary type to have a size other
-than that which would have been chosen by default.>
-@dby
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased or atomic object of an elementary type to have a size other
-than that which would have been chosen by default.>
+Making 13.2 (6.1/2) a Recommended Level of Support makes it a requirement
+when Annex C is supported.  This covers volatile and atomic and eliminates
+the conflict between the Recommended Level of Support and this rule.
 
-!corrigendum 13.1(26/2)
+Similarly, C.6(21) conflicts with the Recommended Level of Support. We don't want
+the representation of a packed array of Boolean to depend on other keywords
+(like aliased) or pragmas that apply to the type. (That could cause silent
+representation changes during maintenance.) Thus, this rule is deleted.
 
-@drepl
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased object of a composite type, or an object whose
-type is by-reference, to have a size smaller than that which would have been
-chosen by default.>
-@dby
-@xbullet<An implementation need not support a nonconfirming representation item
-if it could cause an aliased or atomic object of a composite type, or an object whose
-type is by-reference, to have a size smaller than that which would have been
-chosen by default.>
 
 !corrigendum 13.2(6.1/2)
 
-@drepl
+@ddel
 If a packed type has a component that  is not of a by-reference type and has
 no aliased part, then such a component need not be aligned according to the
 Alignment of its subtype; in particular it need not be allocated on
 a storage element boundary.
+
+!corrigendum 13.2(7)
+
+@dinst
+The recommended level of support for pragma Pack is:
+@dinsa
+@xindent<For a packed type that has a component that is of a by-reference type,
+aliased, volatile, or atomic, the component shall be aligned according to
+the alignment of its subtype; in particular it shall be aligned on a
+storage element boundary.>
+
+!corrigendum 13.2(9)
+
+@drepl
+@xbullet<For a packed array type, if the component subtype's Size is less than
+or equal to the word size, and Component_Size is not specified for the type,
+Component_Size should be less than or equal to the Size of the component subtype,
+rounded up to the nearest factor of the word size.>
 @dby
-The component of a packed type need not be aligned according to the
-Alignment of its subtype; in particular it need not be allocated on
-a storage element boundary.
+@xbullet<For a packed array type, if the component subtype's Size is less than
+or equal to the word size, and Component_Size is not specified for the type,
+Component_Size should be less than or equal to the Size of the component subtype,
+rounded up to the nearest factor of the word size. If the array component is
+required to be aligned according to its subtype and the results of packing are
+not so aligned, pragma pack should be rejected.>
 
 !corrigendum C.6(10)
 
@@ -127,6 +117,20 @@
 if the implementation cannot support the indivisible and independent reads and updates
 required by the pragma (see below).
 
+!corrigendum C.6(11)
+
+@drepl
+It is illegal to specify the Size attribute of an atomic object, the Component_Size
+attribute for an array type with atomic components, or the layout attributes of an
+atomic component, in a way that prevents the implementation from performing the
+required indivisible reads and updates.
+@dby
+It is illegal to specify the Size attribute of an atomic object, the Component_Size
+attribute for an array type with atomic components, or the layout attributes of an
+atomic component, in a way that prevents the implementation from performing the
+required indivisible and independent reads and updates.
+
+
 !corrigendum C.6(21)
 
 @ddel
@@ -136,8 +140,9 @@
 
 !ACATS test
 
-Since this only allows (rather than requires) an implementation to reject something,
-it would be hard to usefully test.
+ACATS tests confirming rejection of pragma Pack combined with Atomic_Components
+for small types like Boolean on all targets but bit addressable targets should
+be implemented.
 
 !appendix
 
@@ -314,7 +319,7 @@
 
 ****************************************************************
 
-From: Robert Dewar
+From: Pascal Leroy
 Sent: Thursday, March 30, 2006  8:25 AM
 
 > is that behavior OK? forbidden? mandated?
@@ -695,7 +700,7 @@
 
 ****************************************************************
 
-From: Robert Dewar
+From: Randy Brukardt
 Sent: Thursday, March 30, 2006  5:47 PM
 
 > So how *will* your compiler handle these two cases?
@@ -1447,6 +1452,48 @@
 Not really.
 The question was about independent addressability. You can have 
 indivisible updates without independent addressability.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 21, 2007  8:11 AM
+
+You must not use "must" in an ISO standard.
+You shall use "shall" instead... ;-)
+
+(Although you didn't violate this one,
+you may not use "may not" either.  You
+shall use "shall not" or you might use
+"might not" instead.)
+
+> ...
+> !wording
+> 
+> 13.2 (6.1/2) is renumbered 13.2 (7.1/3) and reads:
+> 
+> For a packed type that has a component that is of a by-reference type,
+> aliased, volatile or atomic, the component must be aligned according to
+
+Please fully "comma-ize" lists of more than two elements.  Hence,
+"... volatile, or atomic, ..."
+
+> the alignment of its subtype; in particular it must be aligned on a
+> storage element boundary.
+
+Why does this last part follow?  Can't a subtype have an alignment
+of zero?
+
+> 
+> 13.2 (9) append:
+> 
+> If the array component must be aligned according to its subtype and the
+> results of packing are not so aligned, pragma pack should be rejected.
+
+This is worded somewhat ambiguously, here using "must" when probably
+some other word would make more sense.
+
+
+[Editor's note: These editorial changes were made in version /02 of the AI.]
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent