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

--- ai05s/ai05-0009-1.txt	2008/05/10 05:14:33	1.5
+++ ai05s/ai05-0009-1.txt	2008/05/29 04:36:46	1.6
@@ -1,4 +1,4 @@
-!standard 9.10(1)                                      08-02-26    AI05-0009-1/04
+!standard 9.10(1)                                      08-05-16    AI05-0009-1/05
 !standard 13.1(15/1)
 !standard 13.2(9)
 !standard 13.3(13)
@@ -45,42 +45,29 @@
 If two different objects, including nonoverlapping parts of the same
 object, are independently addressable, they can be manipulated
 concurrently by two different tasks without synchronization.
-Normally, any two nonoverlapping objects are independently addressable.
-However, if a non-confirming representation item is used to specify packing,
-record layout, Component_Size, or the convention for a given composite object
-that is not atomic, then it is unspecified whether or not two nonoverlapping
-parts of that composite object are independently addressable.
-Notwithstanding the previous, an atomic component is always independently
-addressable from any other nonoverlapping part of any enclosing object.
-
-AARM Ramification: A component to which pragma Independent or pragma
-Independent_Components (see C.6) applies is always independently
-addressable from any other nonoverlapping component of the enclosing
-object. If that is not true, the pragma must be rejected.
+Any two nonoverlapping objects are independently addressable if
+either object is atomic, if a pragma Independent applies to either
+object (see C.6), or if either is a component of a composite object
+to which pragma Independent_Components applies (see C.6). Otherwise,
+two nonoverlapping objects are independently addressable
+except when they are both parts of a composite object for which
+a non-confirming representation item is used to specify
+packing, record layout, Component_Size, or convention, in which case
+it is unspecified whether the parts are independently addressable.
+
+AARM Ramification: If the compiler cannot guarantee that an object
+(including a component) to which pragma Independent or pragma
+Independent_Components (see C.6) applies is independently
+addressable from any other nonoverlapping object, then the pragma
+must be rejected.
 
-AARM Ramification: An atomic object (including atomic components, see C.6)
+Similarly, an atomic object (including atomic components, see C.6)
 is always independently addressable from any other nonoverlapping object.
 Any representation item which would prevent this from being true should
 be rejected, notwithstanding what this Standard says elsewhere.
+End AARM Ramification.
 
-[Editor's notes: There are two problems with this wording that I can't seem
-to figure out.
-(1) I can't figure out how to work atomic components of non-atomic objects
-into this wording. The best I can do is given above, and it is barf-inducing.
-(2) I not convinced this actually works in the case of a non-confirming
-representation item and a pragma Independent_Components. Consider:
-    type OK is array (1..4) of Character;
-    for OK'Component_Size use 16;
-    pragma Independent_Components (OK);
-type OK should have independent addressable components if these clauses
-are accepted (and I'd expect that they would be on most compilers). But
-the above wording says that whether this is true is unspecified.
-One can argue that the wording of C.6 supercedes this (and that is what
-I wrote in the AARM note), but I don't like the conflicting wording - it
-is confusing at best and misleading at worst. Maybe add some "Redundant"
-text to explain this??]
 
-
 Update the AARM notes in 13.1 (8.v, 8.w; 8.hh) to add the
 new pragmas independent and independent components.
 
@@ -103,7 +90,7 @@
 item for a derived type, the confirming representation item does not override
 the inherited one. Thus the derived type has both a specified confirming and
 an inherited non-confirming representation item -- this means that rules
-that exclude confirming representation items still apply to this type.
+that don't apply to confirming representation items still apply to this type.
 
 
 Change 13.2(9) as follows:
@@ -122,12 +109,12 @@
 program execution is erroneous. 
 
 AARM Discussion: "Appropriate for the entity" covers cases such as
-misaligned addresses, code addresses for data objects (and vice versa),
-and addresses which would force objects that are supposed to be independently
-addressable to not be. Such addresses may be "valid" as they designate
-locations that are accessible to the program, but the program execution
-is still erroneous (meaning that implementations do not have to worry
-about these cases).
+misaligned addresses, read-only code addresses for data objects (and
+non-executable data addresses for code objects), and addresses which would
+force objects that are supposed to be independently addressable to not be.
+Such addresses may be "valid" as they designate locations that are
+accessible to the program, but the program execution is still erroneous
+(meaning that implementations do not have to worry about these cases).
 
 
 Add after C.6(4): [Syntax]
@@ -256,7 +243,9 @@
 "valid" (where an address isn't valid if it causes some violation of
 semantics even if it is legitimate address for the target), but
 hardly anyone [Editor's note: except Tucker! ;-)] reads this paragraph
-that way. Thus we add clarifying wording and an AARM note.
+that way. After all, Ada has a fairly specific meaning for a "valid"
+value of a type (see 13.9.1), and it mainly refers to the actual bit
+pattern of the value. Thus we add clarifying wording and an AARM note.
 
 
 
@@ -2309,7 +2298,7 @@
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Thursday, February 28, 2007 12:28 AM
+Sent: Thursday, February 28, 2008 12:28 AM
 
 I've completed an update of AI05-0009-1 [this is version /04 of the
 AI - ED] based on the ARG discussion from the Paris meeting (the
@@ -2317,6 +2306,47 @@
 have the wording right and all of the cases covered. You can find
 my concerns by reading the "Editor's notes" in the AI. Comments and
 suggestions are welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 10, 2008 10:49 PM
+
+I agree that the wording is problematic.  Suppose we change 9.10 to say roughly
+the following:
+
+    If two different objects, including nonoverlapping parts of the same
+    object, are independently addressable, they can be manipulated
+    concurrently by two different tasks without synchronization.
+    Any two nonoverlapping objects are independently addressable if
+    either object is atomic, if a pragma Independent applies to either
+    object (see C.6), or if either is a component of a composite object
+    to which pragma Independent_Components applies (see C.6).  Otherwise,
+    two nonoverlapping objects are independently addressable
+    except when they are both parts of a composite object for which
+    a non-confirming representation item is used to specify
+    packing, record layout, Component_Size, or convention, in which case
+    it is unspecified whether the parts are independently addressable.
+
+Essentially, by putting the rule about atomic and pragma Independent* up front,
+and putting the rest in an "otherwise" clause, we give the right precedence.
+
+We could simplify the above by defining what it means for a "declaration of
+independence" to apply to an object... ;-) ;-), then we get:
+
+     ... if either object is atomic, or if a declaration of
+     independence applies to either object (see C.6).  Otherwise, ...
+
+Wouldn't that be fun?  Right up there with initialized alligators and pure streams.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, March 11, 2008 11:12 AM
+
+> Wouldn't that be fun?
+
+:-) :-) 
 
 ****************************************************************