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

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

--- ai12s/ai12-0210-1.txt	2019/02/08 02:37:53	1.7
+++ ai12s/ai12-0210-1.txt	2019/05/14 06:31:23	1.8
@@ -1,4 +1,4 @@
-!standard 7.3.2(23/3)                                 19-02-06  AI12-0210-1/02
+!standard 7.3.2(23/3)                                 19-05-14  AI12-0210-1/03
 !class ramification 16-12-19
 !status work item 16-12-19
 !status received 16-09-29
@@ -123,18 +123,29 @@
   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 type-invariant preserving subprogram might assign
      an invariant-violating value to a global variable that is
      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.
+     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
+     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.
-   - No invariant checks are performed for screened (see AI-191) parts of
-     tagged parameters and function results.
+     not itself type-invariant preserving. 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 
+     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.
    - Consider a package P which declares an invariant-bearing private type T
      and a generic package P.G1, which in turn declares another generic package
      P.G1.G2. Outside of package P, there are declarations of an
@@ -144,10 +155,11 @@
      preserving (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.
+     invariant-violating value. So long as a nested generic of a
+     nested generic unit of P is not declared, no such leaks are possible.
 
-  All of these holes require cooperation of some form from
-  within the immediate scope of the invariant-bearing type. 
+  All of these leaks require cooperation of some form (as detailed
+  above) from within the immediate scope of the invariant-bearing type. 
 
 !discussion
 
@@ -255,8 +267,8 @@
 
 ---
 
-Note that this AI includes a reference to screened components, which are
-defined in AI12-0191-1.
+Note that this AI includes a reference to parts of the nominal type, a term
+which was defined in AI12-0191-1.
 
 !ASIS
 
@@ -508,7 +520,7 @@
 ****************************************************************
 
 From: Steve Baird
-Sent: Wednesday, February 6, 2018  7:28 PM
+Sent: Wednesday, February 6, 2019  7:28 PM
 
 Attached is another attempt at wording for AI12-0210, reflecting the group's 
 decision to take no action other than to add an explanatory AARM note.
@@ -521,7 +533,7 @@
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Wednesday, February 6, 2018  9:43 PM
+Sent: Wednesday, February 6, 2019  9:43 PM
 
 ...
 > As before, thanks to Randy for preliminary review but don't blame him 
@@ -611,8 +623,8 @@
      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
      invariant, avoiding the declaration of types with 
-     access-valued components of T in the package that contains T is 
-     sufficient to prevent this leak.}
+     access-valued components 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
@@ -646,7 +658,7 @@
 ****************************************************************
 
 From: Tullio Vardanega
-Sent: Thursday, February 7, 2018  2:06 AM
+Sent: Thursday, February 7, 2019  2:06 AM
 
 I find the "avoidance advice" text that Randy proposed adding very useful 
 indeed.

Questions? Ask the ACAA Technical Agent