CVS difference for 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