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

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

--- ai05s/ai05-0265-1.txt	2011/12/17 06:05:14	1.3
+++ ai05s/ai05-0265-1.txt	2012/01/05 06:19:33	1.4
@@ -37,7 +37,7 @@
 !standard  A.18.25(0)
 !class binding interpretation 11-10-27
 !status Amendment 2012 11-10-27
-!status ARG Approved 8-0-1  11-12-11
+!status ARG Approved 8-0-1  11-11-12
 !status work item 11-10-27
 !status received 10-10-02
 !priority Low
@@ -80,11 +80,11 @@
 of the <container-kind> that contains the element designated by Position {is
 prohibited during the execution of the call on Process.all}.
 
-Modify A.18.2(137/2), A.18.2(141/2), A.18.2(145/2), A.18.3(85/3), A.18.4(40/3), A.18.7(95/2), 
+Modify A.18.2(137/2), A.18.2(141/2), A.18.2(145/2), A.18.3(85/3), A.18.4(40/3), A.18.7(95/2),
 A.18.10(118/3), A.18.18(48/3), A.18.18(50/3):
 
 [Program_Error is propagated if Process.all tampers]{Tampering} with the elements of Container
-{is prohibited during the execution of the call on Process.all}. 
+{is prohibited during the execution of the call on Process.all}.
 
 Modify A.18.10(152/3), A.18.10(211/3), A.18.10(215/3):
 
@@ -95,7 +95,7 @@
 Modify A.18.2(228/2), A.18.3(142/2), A.18.4(75/2), A.18.7(86/2), A.18.10(151/3):
 
 [Program_Error is propagated if Process.all tampers]{Tampering} with the cursors of Container
-{is prohibited during the execution of a call on Process.all}. 
+{is prohibited during the execution of a call on Process.all}.
 
 Modify A.18.2(147.14/3), A.18.2(147.17/3), A.18.3(86.7/3), A.18.3(86.10/3), A.18.4(41.7/3),
 A.18.4(41.10/3), A.18.7(36.6/3), A.18.7(96.11/3), A.18.10(126/3), A.18.10(129/3), A.18.18(57/3),
@@ -120,19 +120,19 @@
 It is a bounded error to assign from a bounded <container-name> object while tampering with elements
 Redundant[or cursors] of that object is prohibited. Either Program_Error is raised by the assignment,
 execution proceeds with the target object prohibiting tampering with elements Redundant[or cursors], or
-execution proceeds normally. 
+execution proceeds normally.
 
 Erroneous Execution
 
 When a bounded <container-name> object <V> is finalized, if tampering with cursors is prohibited for <V>
-other than due to an assignment from another <container-name>, then execution is erroneous. 
+other than due to an assignment from another <container-name>, then execution is erroneous.
 
 AARM Reason: This is a tampering event, but since the implementation is not allowed to use Ada.Finalization,
 it is not possible in a pure Ada implementation to detect this error. (There is no Finalize routine that will
 be called that could make the check.) Since the check probably cannot be made, the bad effects that could
 occur (such as an iterator going into an infinite loop or accessing a non-existent element) cannot be
 prevented and we have to allow anything. We do allow re-assigning an object that only prohibits tampering
-because it was copied from another object as that cannot cause any negative effects. 
+because it was copied from another object as that cannot cause any negative effects.
 
 
 !discussion
@@ -882,5 +882,107 @@
 
 Is this better? (Has to be :-), it matches the intended implementation.) Any
 suggestions for improvement?
+
+****************************************************************
+
+Wording proposed Saturday, November 12, 2011 3:21 PM during Denver ARG meeting.
+This was generated by the subgroup of Randy, Steve, and Tucker during the
+extended lunch break.
+
+Add an AARM note after A.18.2(93.1/3):
+
+AARM Ramification: We don't need to explicitly mention assignment_statement,
+because that finalizes the target parameter as part of the operation, and
+finalization is already defined as tampering.
+
+[Make a similar change in the tampering with cursors rules for all other
+containers.]
+
+Add in A.18.19:
+
+Bounded Errors
+
+It is a bounded error to assign from an object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised by the
+assignment, the target object prohibits tampering with elements [or cursors], or
+execution proceeds normally.
+
+Erroneous Execution
+
+When a bounded vector object V is finalized, if tampering with cursors is
+prohibited for V, other than due to an assignment from another vector, then
+execution is erroneous.
+
+AARM Reason: This is a tampering event, but since the implementation is not
+allowed to use Ada.Finalization, it is not possible in a pure Ada implementation
+to detect this error. (There is no Finalize routine that will be called to make
+the check.) Since the check probably cannot be made, the bad effects that could
+occur (such as an iterator going into an infinite loop or accessing a
+non-existent element) cannot be prevented and we have to allow anything. We do
+allow re-assigning an object that only prohibits tampering because it was copied
+from another object as that cannot cause any negative effects.
+
+[Add similar text to every bounded container.]
+
+===============
+
+How we got to the above wording:
+
+We don't need to mention assignment_statements in the tampering rules for
+the reasons described in the new AARM note. We wasted a lot of time on this
+one.
+
+We do need to make tampering on assignment to be erroneous for the bounded
+containers, because there is no Finalize routine that will be called in that
+case to make the check.
+
+Steve has suggested that since we can now describe the state, we could
+simply say that the state might be copied. And not a bounded error. Tucker
+thought that was bad for some reason that I [Randy] don't recall.
+
+This led to a suggestion that there really isn't a problem; it's possible
+to tell between "real" tampering and "copied" tampering. The container could
+include a self-identification associated with the tampering state. This could be
+checked whenever the tampering check occurs, and if it doesn't identify the
+container object involved, then the tampering is not real and should be cleared.
+That would fix the problem. Well, almost all cases of the problem:
+T := S; Deallocate S; Allocate new which ends up in the same memory as S; S := T;
+This could not be detected.
+
+So we really do need the bounded error, and it is rather expensive anyway.
+
+Tucker would like the assignment to be able to raise Program_Error if detected.
+So:
+
+It is a bounded error to assign from an object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised by the
+assignment, the target object prohibits tampering with elements [or cursors], or
+execution proceeds normally.
+
+What about re-assignment? That would be erroneous because of the previous rule.
+Yuck.
+
+Add:
+
+"If the target object prohibits tampering as the result of the assignment, it is
+not erroneous to assign to the target object, notwithstanding the general rule
+for finalizing objects in this state."
+
+Better to change the previous rule:
+
+Erroneous Execution
+
+When a bounded vector object V is finalized, if tampering with cursors is
+prohibited for V, other than due to an assignment from another vector, then
+execution is erroneous.
+
+AARM Reason: This is a tampering event, but since the implementation is not
+allowed to use Ada.Finalization, it is not possible in a pure Ada implementation
+to detect this error. (There is no Finalize routine that will be called to make
+the check.) Since the check probably cannot be made, the bad effects that could
+occur (such as an iterator going into an infinite loop or accessing a
+non-existent element) cannot be prevented and we have to allow anything. We do
+allow re-assigning an object that only prohibits tampering because it was copied
+from another object as that cannot cause any negative effects.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent