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

--- ai05s/ai05-0009-1.txt	2009/03/12 04:48:47	1.11
+++ ai05s/ai05-0009-1.txt	2009/04/24 03:13:10	1.12
@@ -18,11 +18,11 @@
 !priority Medium
 !difficulty Hard
 !qualifier Error
-!subject Confirming rep. clauses and independence
+!subject Confirming representation items and independence
 
 !summary
 
-The incorporation of confirming representation clauses has
+The incorporation of confirming representation items has
 semantic implications for independent addressability.
 Two new pragmas (Independent and Independent_Components) are introduced
 to allow a user to specify that the components of an object of a type
@@ -32,9 +32,9 @@
 independent addressability.
 
 Atomic objects are always independently addressable from any other
-nonoverlapping object (no matter what representation clauses apply).
+nonoverlapping object (no matter what representation items apply).
 
-A derived type can inherit a non-confirming representation clause,
+A derived type can inherit a non-confirming representation item,
 which is still considered non-confirming.
 
 Execution is erroneous if an address clause specifies a valid address
@@ -43,8 +43,8 @@
 !question
 
 9.10(1) says that two nonoverlapping objects are independently addressable unless one or
-more representation clauses are specified for them. AI95-0291-2 says that confirming
-representation clauses don't change the representation of items, so it seems weird that
+more representation items are specified for them. AI95-0291-2 says that confirming
+representation items don't change the representation of items, so it seems weird that
 they can affect independent addressibility. Is this intended? (No.)
 
 !recommendation
@@ -178,13 +178,13 @@
 !discussion
 
 The problem to be addressed is demonstrated by the following (on a
-byte addressable target):
+byte-addressable target):
 
    A : array (1..4) of character;
    for A'Component_Size use 8;
 
 The components of A are no longer independent by the original wording,
-which allows different encodings of the following statements:
+which would have allowed different encodings of the following statements:
 
 A (1) := <char>;
 A (4) := <char>;
@@ -206,34 +206,41 @@
 machine the pragma would be rejected because each component of
 A is not independently addressable.
 
-9.10(1)
+If the Component_Size clause is confirming (as it is likely to be on a
+byte-addressable target), then the new wording also requires that the
+components are independent and therefore the second code sequence is not
+allowed in that case.
+
+More generally, we include "non-confirming" in 9.10(1) so that
+giving a confirming representation item does not change the semantics
+of a program. The original wording violated the language design
+principle explained in 13.1(1.a.2/2).
 
-Including non-confirming removes semantics associated with confirming
-representations. Convention was added to allow non-independent
+We also added Convention to 9.10(1) to allow non-independent
 addressability for conventions other than Ada. Atomic objects always
 have independent addressability compared to any other object (including
 components). This is necessary so that the intent that tasks can
 access such objects safely without (separate) synchronization is
 accomplished.
 
-C.6
-
-Introduces the new pragmas, defining Independent to be applicable to
+The new pragmas are added in C.6, defining Independent to be applicable to
 individual record components, and Independent_Components which
-applies to array and record types.
-Pragma Independent and Independent_Components are similar to Volatile and
+applies to array and record types. Pragma Independent and
+Independent_Components are similar to Volatile and
 Atomic in that only a single entity name is accepted with the pragma.
 
-The minutes from Albuquerque note that pragma Independent_Components
-should be considered for all composite types; however, there is no way
-to remove independence for the discriminants of tasks or components of
-protected types, so the pragma is not needed for those types. Moreover,
-as a representation pragma, it is not allowed on partial views
-(by 13.1(9)), so we only need to allow array and record types.
-
-We add redundant wording in C.6(14) so that the new pragmas have some
-description of their semantics in C.6 (otherwise, their meaning is
-mysterious).
+The minutes from the Albuquerque ARG meeting note that pragma
+Independent_Components should be considered for all composite types;
+however, there is no way to remove independence for the discriminants
+of tasks or components of protected types, so the pragma is not needed
+for those types. Moreover, as a representation pragma, it is not
+allowed on partial views (by 13.1(9)), so we only need to allow
+array and record types.
+
+We added the term specify as independently addressable C.6(14.1)
+to simplify the wording needed in 9.10(1), and to ensure that the
+pragmas have a definition in C.6 (defining them completely in 9.10(1)
+would make C.6 mysterious).
 
 
 A separate problem was identified during the preparation of this AI.
@@ -243,8 +250,8 @@
 we want it to remain non-confirming.
 
 We also noted that 13.2(9) seems to allow different behavior if a
-confirming representation clause is given, which breaks the model that
-confirming representation clauses never change anything.
+confirming representation item is given, which breaks the model that
+confirming representation items never change anything.
 
 It was also noted that an address specified in an address clause could
 be used to break independent addressibility in places where it was