CVS difference for ai12s/ai12-0210-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0210-1.txt

--- ai12s/ai12-0210-1.txt	2019/05/14 06:31:23	1.8
+++ ai12s/ai12-0210-1.txt	2019/06/11 04:13:54	1.9
@@ -1,4 +1,4 @@
-!standard 7.3.2(23/3)                                 19-05-14  AI12-0210-1/03
+!standard 7.3.2(23/3)                                 19-06-03  AI12-0210-1/04
 !class ramification 16-12-19
 !status work item 16-12-19
 !status received 16-09-29
@@ -123,26 +123,26 @@
   The list of known techniques for achieving this kind of leak
   (ignoring things like erroneous execution and the various
   forms of unchecked type conversion) consists of:
-   - A type-invariant preserving subprogram might assign
+   - A boundary subprogram might assign
      an invariant-violating value to a global variable that is
-     visible to client code.
+     visible to client code. 
    - Invariant checks on subprogram return are not performed on objects
      that are accessible only through access-valued components of other
      objects. This can only cause a leak if there is a type with 
      access-valued components that is used as a parameter or result type
-     of a type-invariant preserving subprogram. For a type T that has a type
+     of a boundary subprogram. For a type T that has a type
      invariant, avoiding the declaration of types with 
      access-valued components designating objects with parts of T in the 
      package that contains T is sufficient to prevent this leak.
    - A client could call through an access-to-subprogram value and reach a
      subprogram body that has visibility on the full declaration of a type;
      no invariant checks will be performed if the designated subprogram is
-     not itself type-invariant preserving. This leak can only happen if
+     not itself a boundary subprogram. This leak can only happen if
      an access-to-subprogram value of a subprogram that is not visible to
      clients is passed out to clients.
    - Invariant checks are only performed for parts of the nominal type for
      tagged parameters and function results. For this leak to occur for a
-     type T that has a type invariant, the body of a type-invariant preserving 
+     type T that has a type invariant, the body of a boundary 
      subprogram of T needs to have visibility on a type extension that has
      components of T or access-to-T and also has an ancestor type (or class)
      as a parameter or result of the subprogram.
@@ -151,8 +151,8 @@
      P.G1.G2. Outside of package P, there are declarations of an
      instantiation I1 of P.G1 and an instantiation I2 of I1.G2. I2
      can declare visible subprograms whose bodies see the full
-     view of T and yet these subprograms are not type-invariant
-     preserving (because the generic I1.G2 is not declared within the
+     view of T and yet these subprograms are not boundary subprograms
+     (because the generic I1.G2 is not declared within the
      immediate scope of T - G1.G2 is, but that's irrelevant). So a call to
      one of these subprograms from outside of P could yield an
      invariant-violating value. So long as a nested generic of a
@@ -237,7 +237,7 @@
 
 An instance of such a generic will not be in the "extended immediate scope"
 of the private type and so any visible subprograms that the instance might
-declare will not be "type-invariant preserving" for the private type.
+declare will not be "boundary subprogram" for the private type.
 But the private type can't be mentioned in the profile of such a subprogram
 unless incomplete types and access types are involved somehow. We are not
 trying to plug all such holes (for example, we also don't worry about

Questions? Ask the ACAA Technical Agent