CVS difference for ai05s/ai05-0148-1.txt
--- ai05s/ai05-0148-1.txt 2009/06/26 01:49:35 1.5
+++ ai05s/ai05-0148-1.txt 2009/07/11 03:06:22 1.6
@@ -1,10 +1,10 @@
-!standard 3.10.2(13/2) 09-06-25 AI05-0148-1/05
+!standard 3.10.2(13.1/2) 09-06-25 AI05-0148-1/05
!standard 3.10.2(19/2)
!standard 4.6(24.17/2)
!standard 4.6(48)
!class Amendment 09-04-12
!status Amendment 201Z 09-06-25
-!status ARG Approved 6-0-0 09-06-14
+!status ARG Approved 7-0-0 09-06-14
!status work item 09-04-12
!status received 09-04-12
!priority Medium
@@ -86,12 +86,12 @@
Note that a library-level object of an anonymous access type
can only designate library-level objects.
-The null value is considered libary-level for the purposes
+The null value is considered library-level for the purposes
of these checks.
!wording
-Add the following after 3.10.2(13/2):
+Add the following after 3.10.2(13.1/2):
The accessibility level of the type of a stand-alone object of an
anonymous access-to-object type is determined by the accessibility
@@ -107,6 +107,29 @@
is not considered to be statically deeper, nor statically shallower,
than any other.
+Add more text to the AARM Implementation Note (after 3.10.2(22.ff)):
+
+ The implementation of accessibility checks for stand-alone objects of
+ anonyomous access-to-object types can be similar to that for anonymous
+ access-to-object parameters. A static level sufficies; it can be calculated
+ using rules similar to those previously described for access parameters.
+
+ 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. Similarly, one can assign
+ a more global access parameter to a more local stand-alone access variable.
+
+ For these cases, it is important to note that the "correct" static
+ accessibility level for an access parameter assigned to a stand-alone
+ access parameter is the minimum of the passed in level and the static
+ accessibility level of the stand-alone object itself. This is true since
+ the static accessibility level passed in might be deeper than that of the
+ stand-alone object, but the dynamic accessibility of the passed in object
+ clearly must be shallower than the stand-alone object (whatever is passed
+ in must live at least as long as the subprogram call). We do not need to
+ keep a more local static level as objects statically deeper than the
+ stand-alone object cannot be stored into the stand-alone object.
+
Change 4.6(24.17/2):
* The accessibility level of the operand type shall not be statically
@@ -118,6 +141,10 @@
normally apply (see 12.3), this rule applies also in the private part
of an instance of a generic unit.
+ AARM Reason: We prohibit storing accesses to objects deeper than a
+ stand-alone object of a anonymous access-to-object (even while we
+ allow storing all other accesses) in order to prevent dangling accesses.
+
Change 4.6(48):
* For an access-to-object type, a check is made that the accessibility
@@ -125,9 +152,9 @@
type{, unless the target is a stand-alone object of an anonymous
access type}. {If the target is such a stand-alone object, a check is
made that the accessibility level of the operand type is not deeper
- than that of the declaration of the stand-alone object.
- [Redundant: The accessibility level of the target type becomes that of
- the operand type.]}
+ than that of the declaration of the stand-alone object;
+ [Redundant: if the check succeeds, the accessibility level of
+ the target type becomes that of the operand type].}
!discussion
@@ -173,20 +200,59 @@
dynamic flexibility we are proposing here for access-to-object types,
because access-to-subprogram parameters are not dynamic.
+More local objects
+
+Despite this being a dynamic accessibility model, it is not allowed
+to store a more local access into a stand-alone object of an anonymous
+access-to-object type. This is necessary to prevent dangling references
+which would be very hard to detect.
+
+Consider:
+
+ declare
+ Obj : access Integer;
+
+ procedure Do_It (Value : in Integer) is
+ Local : aliased Integer := Value;
+ begin
+ if Value mod 3 = 0 then
+ Obj := Local'Access; -- (1)
+ else
+ Obj.all := Value + Obj.all; -- (2)
+ end if;
+ end Do_It;
+ begin
+ Do_It (3);
+ Do_It (4);
+ end;
+
+The assignment at (1) is statically illegal. If it was not, we would store
+an access to a more local object into Obj. When the first call to Do_It
+returns, that object ceases to exist, but Obj still has an access to it.
+The second call to Do_It then uses Obj at (2). This references an object
+that no longer exists (the Local for Do_It (3), the Local for Do_It (4) is
+a different object, at least logically). Detecting this would require
+accessibility checks at dereferences and a complex scheme of nesting detection.
+(A simple stack check doesn't work, that can be seen in this case where the
+level of the dangling, destroyed object is identical to one that exists,
+but it the object that exists is not the correct one.) The needed check would
+require far too much overhead (and it would be distributed overhead).
+
+
Implementation Issues
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
+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
+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
+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:
@@ -200,8 +266,8 @@
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"
+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
@@ -285,14 +351,76 @@
return Result; -- Fails accessibility check
end Reverse;
+!corrigendum 3.10.2(13.1/2)
+
+@dinsa
+@xbullet<The accessibility level of the anonymous access type of an access
+parameter specifying an access-to-subprogram type is deeper than that of
+any master; all such anonymous access types have this same level.>
+@dinst
+@xbullet<The accessibility level of the type of a stand-alone object of an
+anonymous access-to-object type is determined by the accessibility
+level of the type of the access value most recently assigned to the
+object, but is never deeper than that of the declaration of the
+stand-alone object.>
+
+!corrigendum 3.10.2(19/2)
+
+@dinsa
+@xbullet<The statically deeper relationship does not apply to the accessibility
+level of the anonymous type of an access parameter specifying an
+access-to-object type; that is, such an accessibility level is not
+considered to be statically deeper, nor statically shallower, than
+any other.>
+@dinst
+@xbullet<The statically deeper relationship does not apply to the
+accessibility level of the type of a stand-alone object of an
+anonymous access-to-object type; that is, such an accessibility level
+is not considered to be statically deeper, nor statically shallower,
+than any other.>
+
+
+!corrigendum 4.6(24.17/2)
+
+@drepl
+@xinbull<The accessibility level of the operand type shall not be statically
+deeper than that of the target type. In 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.>
+@dby
+@xinbull<The accessibility level of the operand type shall not be statically
+deeper than that of the target type, unless the target is a
+stand-alone object of an anonymous access type. If the target is
+such a stand-alone object, the accessibility level of the operand type
+shall not be statically deeper than that of the declaration of the
+stand-alone object. In 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.>
+
+!Corrigendum 4.6(48)
+
+@drepl
+@xinbull<For an access-to-object type, a check is made that the accessibility
+level of the operand type is not deeper than that of the target
+type.>
+@dby
+@xinbull<For an access-to-object type, a check is made that the accessibility
+level of the operand type is not deeper than that of the target
+type, unless the target is a stand-alone object of an anonymous
+access type. If the target is such a stand-alone object, a check is
+made that the accessibility level of the operand type is not deeper
+than that of the declaration of the stand-alone object; if the
+check suceeds, the accessibility level of the target type becomes that of
+the operand type.>
+
!ACATS test
ACATS C-Tests are needed to check that the accessibility is retained.
!appendix
-[This idea grew out of the volumnous e-mail threads found in
+[This idea grew out of the voluminous e-mail threads found in
AI05-138-1. - Editor.]
****************************************************************
@@ -956,11 +1084,3 @@
****************************************************************
-From: Bob Duff
-Sent: Monday, April 13, 2009 x:xx PM
-
-****************************************************************
-From: Bob Duff
-Sent: Monday, April 13, 2009 x:xx PM
-
-****************************************************************
Questions? Ask the ACAA Technical Agent