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

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

--- ai05s/ai05-0027-1.txt	2007/01/13 05:25:56	1.3
+++ ai05s/ai05-0027-1.txt	2007/10/31 02:24:49	1.4
@@ -1,4 +1,7 @@
-!standard A.18.2(238/2)                                   06-12-13    AI05-0027-1/02
+!standard A.18.2(239/2)                                   07-10-28    AI05-0027-1/03
+!standard A.18.3(152/2)
+!standard A.18.4(75/2)
+!standard A.18.7(96/2)
 !class binding interpretation 06-11-13
 !status work item 06-11-13
 !status received 06-11-03
@@ -6,22 +9,60 @@
 !difficulty Easy
 !qualifier Omission
 !subject Behavior of containers operations when passed finalized container objects
+If an operation is passed a container object that has been finalized,
+it is a bounded error.  If the operation is read-only, then either
+the operation proceeds as though the container were empty, or
+Constraint_Error or Program_Error is raised.
+If a finalized container is passed to an operation that would update
+the container, Constraint_Error or Program_Error is raised.
+What happens in container operations when passed a finalized container object?
 (See Summary.)
+Add the following after A.18.2(239):
+   It is a bounded error to call any subprogram declared in Containers.Vectors
+   when the associated container has been finalized.  If the operation takes 
+   Container as an IN OUT parameter, then it raises Constraint_Error or 
+   Program_Error.  Otherwise, the operation either proceeds as it would 
+   for an empty container, or it raises Constraint_Error or Program_Error.
+Make corresponding additions to all other container packages,
+after A.18.3(152), after A.18.4(75) [needs "Bounded Error" label 
+as well], and after A.18.7(96) [needs "Bounded Error" label].
+It requires some circumlocution (though see the example for a plausible
+situation) to create a situation where an operation can be applied to a 
+finalized container. Nevertheless, we don't want such an operation 
+to de-finalize the container, and thereby create storage
+leaks or worse. Hence, we do not allow any operation that updates the
+container to proceed, and any other operation either raises an exception,
+or proceeds as though the container were empty. This minimizes any
+distributed overhead associated with handling the finalized case (because
+all non-updating operations need not distinguish a finalized state
+from an empty state), while ensuring that no storage leak or potentially
+erroneous execution is introduced by such "late" operations.  
+We allow Constraint_Error rather than Program_Error for efficiency reasons as
+well, since many of the operations that attempt to update an empty 
+container will already raise Constraint_Error. It is only the updating
+operations that allow for the container to start out empty that will need an
+explicit check for the finalized state.
+We have suggesting adding this paragraph *before* the discussion of ambiguous
+cursors, as we want that discussion to flow right into the discussion of
+invalid curaors.

Questions? Ask the ACAA Technical Agent