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

--- ai05s/ai05-0024-1.txt	2006/11/14 01:34:35	1.4
+++ ai05s/ai05-0024-1.txt	2006/12/16 03:13:18	1.5
@@ -2235,3 +2235,94 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Date: Monday, November 13, 2006  7:44 PM
+
+In a separate response, I proposed using an accessibility
+"anchor" analogous to the "master" record used by some
+run-time systems to link together stack frames that contain
+task objects or finalizable objects.  It seems like it
+might be useful to take Gary's example and try to annotate
+it with where these "anchors" would be created, and how
+they could be used to do the checking.
+
+See below...
+
+Gary Dismukes wrote:
+> The discussion we had a while back about accessibility checks (initiated
+> by Steve Baird's posting) led me to start thinking about cases that could
+> pose problems for using static levels to implement the checks for allocators.
+> I think there was general agreement that the intent is certainly that it
+> should be possible to use static levels, and that if dynamic levels must be
+> maintained this could lead to real difficulties (for example because of cases
+> involving multiple task stacks).  That segued into a discussion of problems
+> related to accessibility checking within task entries with class-wide
+> parameters, and how we might restrict those (discussion still not fully
+> resolved AFAIK, to be continued I believe at the ARG meeting).  Here I'm
+> looking at a different sort of case, with no tasks involved.
+> 
+> Consider this example that uses an anonymous access-to-subprogram type.
+> 
+> procedure Test is
+> 
+>    type T1 is tagged null record;
+> 
+>    procedure Proc_1 (AP : access procedure (T1C : T1'Class)) is
+> 
+>       type Ref is access all T1'Class;
+> 
+>       type NT1 is new T1 with null record;
+>       XNT1 : NT1;
+
+--> anchor(#1) created in this stack frame because we
+     have access-to-class-wide as well as a nested extension.
+     XNT1 (and other objects of type NT1) will refer to this anchor.
+     Remember that there is a new anchor created every time
+     Proc_1 is called.
+> 
+>    begin
+>       AP.all (XNT1);
+>    end Proc_1; 
+> 
+>    procedure Proc_2 is
+> 
+>       type Ref is access all T1'Class;
+
+--> anchor(#2) created in this stack frame because we have an
+     access-to-class-wide type.
+> 
+>       X : Ref;
+> 
+>       procedure Indirect_Proc (T1C : T1'Class) is
+>       begin
+>          X := new T1'Class'(T1C);  -- Should raise C_E if T1C'Tag = NT1'Tag
+
+--> at this point, we look at the anchor associated with the frame
+     where the access type is declared (anchor#2), and we start following
+     it up toward the library level looking for the anchor associated
+     with T1C.  If we find it, the check passes.  If we don't, the
+     check fails.  In this case, following the chain from anchor#2
+     will not find the anchor associated with the T1C passed by the
+     indirect "AP.all(XNT1)" call above.  Instead, anchor#1 points
+     "up" at anchor#2, not vice-versa.
+
+>       end Indirect_Proc;
+> 
+>    begin
+>       Proc_1 (Indirect_Proc'access);
+
+--> Proc_2 calls Proc_1, so anchor#1 points "up" to anchor#2
+
+>       --  Do something with X.all...
+>    end Proc_2;
+> 
+> begin
+>    Proc_2;
+> end;
+
+In this example, the technique seems to produce the correct
+answer, because anchor#1 will *not* be found on the chain
+starting at anchor#2 and going up toward library level.
+
+****************************************************************
+