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.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent