CVS difference for ai05s/ai05-0148-1.txt
--- ai05s/ai05-0148-1.txt 2009/04/30 06:09:30 1.3
+++ ai05s/ai05-0148-1.txt 2009/06/08 03:52:05 1.4
@@ -1,4 +1,4 @@
-!standard 3.10.2(13/2) 09-04-29 AI05-0148-1/03
+!standard 3.10.2(13/2) 09-06-06 AI05-0148-1/04
@@ -170,6 +170,86 @@
being of local accessibility. There seems little need for the
dynamic flexibility we are proposing here for access-to-object types,
because access-to-subprogram parameters are not dynamic.
+Because access-to-object parameters already have dynamic accessibility
+levels, the intent is that these stand-alone variables may be handled
+in a very similar way. Furthermore, if there are no access-to-object
+parameters in scope, then all of the accessibility levels of interest
+will be static, and hence essentially all of the checking can be performed
+at compile-time given some level of flow analysis.
+One important difference between the stand-alone access variables and
+access parameters is that one can assign a local access parameter to
+a more global stand-alone access variable. This is similar to the
+problem of calling a subprogram at a higher level and passing along
+an access parameter. Similarly, one can assign a more global access
+parameter to a more local stand-alone access variable.
+AARM 3.10.2(22.dd/2) addresses the issue of passing an access parameter
+along to another subprogram:
+ * If the actual is an access parameter of an access-to-object type,
+ usually just pass along the level passed in. However, if the static
+ nesting level of the formal (access) parameter is greater than the
+ static nesting level of the actual (access) parameter, the level
+ to be passed is the minimum of the static nesting level of the
+ access parameter and the actual level passed in.
+Note also the paragraph 22.ee indicates that the accessibility level
+passed in for an access parameter is to be ignored when converting
+to a local access type. This is because the accessibility level passed
+in might be deeper than that of the called subprogram. So the "true"
+static accessibility level for an access parameter is generally the
+minimum of the passed in value and the static accessibility level of
+the subprogram itself. This must be remembered when assigning
+the accessibility level of an access parameter to that of a stand-alone
+object. This "min" operation should probably be performed explicitly
+at that point.
+So what can we say about an assignment from an access parameter
+(or access variable) at one level to a stand-alone access variable
+at some other level? First, we should assume the accessibility level
+is normalized as suggested above, namely the value passed in with
+an access parameter is compared against the static level of the
+called subprogram, and reduced to that level if the passed-in value
+is greater. Then the normalized value can safely be assigned to an access
+variable at some other level, subject to first checking that
+it is not deeper than that of the access variable being assigned.
+The normalized value corresponds to the static nesting level, and
+hence is meaningfully compared and assigned to all visible nesting
+ procedure P(X : access T) is
+ Y : access T;
+ procedure Q is
+ Z : access T := X; -- normalize level here
+ Y := Z; -- this is always safe but might
+ -- fail if level of X not normalized
+ -- before being assigned to Z.
+ end Q;
+ end P;
+Interaction with Tasking
+Tasking imposes certain additional concerns with respect to accessibility.
+In particular, inside an accept body, there are two independent stacks
+that are effectively coming together, potentially producing accessibility
+levels that cannot be meaningfully compared. However, access parameters are
+not permitted on entry calls, and there are no OUT parameters of
+an anonymous access type, so in fact accessibility levels from the
+task entry caller never enter into the picture, and we can follow
+the "normal" rules. Up-level references across a task body boundary
+also do not create any special problems (other than the usual danger
+of unsynchronized access to shared variables), because the task body
+is just like a subprogram body from the point of view of static nesting
+and accessibility levels.
Questions? Ask the ACAA Technical Agent