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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0024-1.txt

--- ai05s/ai05-0024-1.txt	2006/11/14 01:19:19	1.3
+++ ai05s/ai05-0024-1.txt	2006/11/14 01:34:35	1.4
@@ -2151,3 +2151,87 @@
+From: Tucker Taft
+Date: Monday, November 13, 2006  7:21 PM
+I think what Gary showed is that the challenge
+is not restricted to inter-task calls.  The fundamental
+problem is when you need to communicate an accessibility
+level at run-time to a subprogram that is not within
+the scope of the caller.  We see this problem in Ada 95 in
+3.10.2(22.dd), where an outer subprogram passes along its access
+parameter to a local nested subprogram.  This nested subprogram
+was not in the scope of the original caller, and as such
+the static accessibility level from the original caller is not
+particularly meaningful.  In specific, if the actual is more nested
+than the outer called subprogram, 3.10.2(22.dd) suggests its
+accessibility level should be adjusted to match that of the
+outer called subprogram's outermost scope.  This makes it
+meaningful to the nested routine being called.
+Unfortunately, unless we want all tagged types to be treated
+like access parameters, we cannot easily adjust an accessibility
+level as part of parameter passing.  Whatever accessibility
+level information we have for a tagged type, it is presumably
+set when the tagged type is elaborated, and readily accessible
+from every object of the type.  The most fundamental
+question is whether the tagged type is more nested than some
+ancestor.  If not more nested, then of course no accessibility
+check associated with nested extensions can fail.
+And in the opposite case, where the type is more nested than
+some ancestor (we will call this a "nested extension"), if
+we are checking against the level of an access type or
+function declared at the library level, then
+the check is certain to fail.  These two cases probably will
+account for 99% of all checks, and the remaining case where
+we have a nested extension, and the access type or function
+against which the check is performed is not declared at library level,
+can probably incur a fair amount of overhead without slowing down
+the program significantly.
+Let us presume that in any scope in which one or more nested
+extensions are declared, or an access type or function is declared
+against which a tagged-type-accessibility check might be performed,
+we create an accessibility "anchor" of some sort with a unique ID
+(such as its address), and arrange that each nested extension refers
+to this anchor.  We then simplify another portion of the checks,
+because if the anchor ID matches that of the function or access type
+against we are checking, we know the check passes.
+We are now down to the cases where the anchor ID doesn't match that
+of the access type/function, and we need to check that the anchor ID
+of the nested extension outlives that of the access-type/function.
+If we presume that anchors are linked to the next longer-lived anchor,
+we can simply walk the chain of anchors starting at the anchor
+of the access-type/function, and if we don't run into the anchor referenced
+by the nested extension before we reach library level, then we raise
+an exception.  Of course there is no real need for a library-level anchor;
+it can be represented by a null pointer.
+Note that these anchors approximate the "master records" that some
+run-time systems create on the stack to link frames containing task
+objects and/or finalizable objects.  Since nested extensions may
+have finalization actions, and access-to-class-wide types generally
+have finalization actions as well (since the designated objects might
+have controlled parts), it might be natural to use a master record
+as the accessibility anchor.  The only clearly new need for such a master
+record would be for a scope declaring one or more functions that
+return class-wide types.  Creating the master record could be
+deferred until it is determined that one or more of the functions
+contain a return statement that needs to perform a dynamic
+tagged-type accessibility check.
+So to summarize the possible approach -- when entering a scope containing
+an access-to-class-wide, function-returning-classwide, or nested extension,
+an accessibility "anchor" or master record must be allocated on the
+stack, and initialized to point to the enclosing anchor/master record.
+When it is time to do a check, presuming the special cases mentioned
+above don't apply, we walk the anchor/master chain starting at that
+of the access-type/function until we find that of the nested extension
+(check then passes), or reach the library level (check then fails).
+It just might work...

Questions? Ask the ACAA Technical Agent