CVS difference for ais/ai-00229.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00229.txt

--- ais/ai-00229.txt	2001/07/14 00:01:48	1.8
+++ ais/ai-00229.txt	2001/09/08 01:42:48	1.9
@@ -1,4 +1,4 @@
-!standard  3.10.2   (32)                             01-05-20  AI95-00229/02
+!standard  3.10.2   (32)                             01-08-31  AI95-00229/03
 !class binding interpretation 00-04-10
 !status ARG approved 6-0-2  01-05-20
 !status work item 01-05-04
@@ -61,9 +61,11 @@
 
 Add after the last sentence of RM95 3.10.2(32):
 
-If the subprogram denoted by P is declared within a generic specification, and
-the expression P'Access occurs within the body of that generic, then the
-ultimate ancestor of S shall be declared within the generic unit.
+If the subprogram denoted by P is declared within a generic unit,
+and the expression P'Access occurs within the body of that generic
+unit, or within the body of a generic unit declared within
+the declarative region of the generic, then the ultimate ancestor
+of S shall be a non-formal type declared within the generic unit.
 
 !discussion
 
@@ -88,7 +90,7 @@
 12.3), this rule applies also in the private part of an instance
 of a generic unit. The profile of P shall be subtype-conformant
 with the designated profile of @i<S>, and shall not be Intrinsic. If
-the subprogram denoted by P is declared within a generic body, S
+the subprogram denoted by P is declared within a generic body, @i<S>
 shall be declared within the generic body.>
 @dby
 @xindent<P'Access yields an access value that designates the subprogram
@@ -98,12 +100,13 @@
 addition to the places where Legality Rules normally apply (see
 12.3), this rule applies also in the private part of an instance
 of a generic unit. The profile of P shall be subtype-conformant
-with the designated profile of @i<S>, and shall not be Intrinsic. If
-the subprogram denoted by P is declared within a generic body, S
-shall be declared within the generic body. If the subprogram denoted by P
-is declared within a generic specification, and the expression P'Access
-occurs within the body of that generic, then ultimate ancestor of @i<S> shall
-be declared within the generic unit.>
+with the designated profile of @i<S>, and shall not be Intrinsic.
+If the subprogram denoted by P is declared within a generic unit,
+and the expression P'Access occurs within the body of that generic
+unit, or within the body of a generic unit declared within
+the declarative region of the generic, then the ultimate ancestor
+of @i<S> shall be a non-formal type declared within the generic unit.
+>
 
 !ACATS test
 
@@ -846,10 +849,10 @@
     end Pack;
 
     package body Pack is
-	  procedure Bar is ...
+        procedure Bar is ...
         procedure Foo is ...
 
-	  V2 : Acc := Bar'Access; -- (2)
+        V2 : Acc := Bar'Access; -- (2)
         V3 : Acc := Foo'Access; -- (3)
     end Pack;
 
@@ -927,7 +930,55 @@
 Humm, this is letter for letter identical with the previous version. So I don't
 see any typo here. Unless you made the same typo a second time.
 
-Your explaination seems like a stretch that ought to be mentioned in the AARM,
+Your explanation seems like a stretch that ought to be mentioned in the AARM,
 as it is less than obvious. But it seems OK to me.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Monday, July 23, 2001  8:30 AM
+
+The latest greatest wording for this AI, as written by Tuck on June 12th,
+reads:
+
+    If the subprogram denoted by P is declared within a generic unit,
+    and the expression P'Access occurs within the body of that generic
+    unit, or within the body of a generic unit declared within
+    the declarative region of the generic, then the ultimate ancestor
+    of S shall be declared within the generic unit.
+
+I believe there is a problem with this wording: the phrase "the ultimate
+ancestor of S shall be declared within the generic unit" seems to allow the
+case where S is a generic formal access type.  I believe we want to disallow
+this case, because at instantiation the actual type corresponding to this
+formal might be declared in an outer scope, and this could be used to create
+dangling references.
+
+Comments?
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, July 24, 2001  1:19 PM
+
+I agree that generic formal access types need to be disallowed here (or we have
+to have a runtime check, which is not the model for these). My first thought
+was that a formal type wasn't a declaration, but since the production is named
+"formal_type_declaration", I think that was wrong. So we need an explicit
+change to the rule.
+
+Perhaps we need to add the phrase "non formal type" to the rule:
+
+... then the ultimate ancestor of S shall be a non-formal type declared within
+the generic unit.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, July 25, 2001  3:58 AM
+
+This looks reasonable.  It would cover the case of a formal access type
+which is a parameter of a formal package, too (a case which we definitely
+want to cover).
 
 *************************************************************

Questions? Ask the ACAA Technical Agent