CVS difference for ai05s/ai05-0234-1.txt
--- ai05s/ai05-0234-1.txt 2011/03/10 03:29:56 1.8
+++ ai05s/ai05-0234-1.txt 2011/03/17 05:46:16 1.9
@@ -1,4 +1,4 @@
-!standard 6.5(21/3) 11-02-16 AI05-0234-1/03
+!standard 6.5(21/3) 11-03-16 AI05-0234-1/04
!class binding interpretation 10-11-15
!status work item 10-11-15
!status received 10-10-31
@@ -66,335 +66,326 @@
!wording
-Insert after Static Semantics section of 3.10.2:
+Change 3.10.2(10/2):
- Dynamic Semantics
- -----------------
+ The accessibility level of an aggregate or the result of a function call
+ [(or equivalent use of an operator)] that is used (in its entirety) to
+ directly initialize part of an object is that of the object being initialized.
+ In other contexts, the accessibility level of an aggregate or the result of a
+ function call is that of the innermost master that evaluates the aggregate or
+ function.
+
+revising it to only describe the aggregate case as follows:
+
+ The accessibility level of an aggregate that is used (in its entirety) to
+ directly initialize part of an object is that of the object being initialized.
+ In other contexts, the accessibility level of an aggregate is that of the
+ innermost master that evaluates the aggregate.
+
+Add the following after 3.10.2(10/2) (Note: '*' denotes a top-level bullet
+and '+' denotes second-level bullets):
+
+ * The accessibility level of the result of a function call is "determined by
+ the point of call" as follows:
+
+ + If the result is used (in its entirety) to directly initialize part of an
+ object, the accessibility level is that of the object being initialized;
+
+ [Author's note: I believe that a bullet may be needed here for coextensions,
+ but this version doesn't yet address that.]
+
+ + If the result is of an anonymous access type and is the operand of an
+ explicit conversion, the accessibility level is that of the target type
+ of the conversion;
+
+ + If the result is of an anonymous access type and defines an access
+ discriminant, the accessibility level is the same as that for an object
+ created by an anonymous allocator that defines an access discriminant
+ (even if the access result is of an access-to-subprogram type).
+
+ + If the call itself defines the result of a function to which one of
+ the above rules applies, these rules are applied recursively;
+
+ + In other cases, the accessibility level of the result is that of the
+ innermost master that evaluates the function call.
+
+ [AARM] Ramification: The accessibility level of a function result object
+ in the case where building in place is optional and the implementation elects
+ not to build in place is the same as if the implementation had decided to
+ build in place. In other words, the effect in terms of masters, lifetimes,
+ and accessibility is transparent to the program. Note that this does not imply
+ that a level has to be passed on calls in cases where the implementation
+ does not build in place, just that the semantics are equivalent.]
+
+ [AARM] Implementation Note: There are several cases where the implementation
+ has to pass in the accessibility level of the result object on a call, to
+ support later rules where the accessibility level is said to be determined
+ by the point of call:
+
+ * when the function result may have a part with access discriminants;
+
+ * when the function result type is an anonymous access type;
+
+ * when the function result is built in place;
+
+ * when the function has an explicitly aliased parameter.
+
+ In particular, this implies passing a level parameter when the result type
+ is class-wide, since descendants may add access discriminants. For most
+ implementations this will mean that functions with controlling results
+ must also have a level parameter.
+
+
+Add a new paragraph after 3.10.2(12.1/2) to cover the case of an access
+discriminant whose value is defined by default:
+
+ + If the value of the access discriminant is determined by a default
+ expression in the discriminant's declaration, the level of the object
+ or subprogram designated by the associated value (or library level
+ if null);
+
+ [AARM] Discussion: This covers the case of a unconstrained subcomponent
+ of a limited type with defaulted access discriminants.
+
+
+Modify 3.10.2(14.5/3) (added as part of AI05-0051-1) as follows, deleting all
+but the first sentence (deleted parts are addressed above as new bullets):
+
+ * Within a return statement, the accessibility level of the anonymous access
+ type of an access result is determined by the point of call. [If the call is
+ the operand of an explicit type conversion, the accessibility level is that
+ of the target access type of the conversion. If the call is an actual
+ parameter of another call or the prefix of a name, the accessibility level
+ is that of the innermost master of the call. If the call defines an access
+ discriminant, the level is the same as that given above for an object
+ created by an anonymous allocator that defines an access discriminant (even
+ if the access result is of an access-to-subprogram type). If the call
+ itself defines the result of a function with an access result, this rule
+ is applied recursively.]
+
+Modify 4.8(10.1/3) (as modified by AI05-0051-1) as follows:
+
+ For any allocator, if the designated type of the allocator is class-wide,
+ then a check is made that the master of the type determined by the
+ subtype_indication, or by the tag of the value of the qualified_expression,
+ includes the elaboration of the type of the allocator. If {any part of} the
+ subtype determined by the subtype_indication or qualified_expression
+ {of the allocator (or by the tag of the value if the type of the qualified
+ expression is class-wide)} [of the allocator] has one or more access
+ discriminants, then a check is made that the accessibility level of the
+ anonymous access type of each access discriminant is not deeper than that
+ of the type of the allocator. Program_Error is raised if either such check
+ fails.
+
+Modify 6.4.1(15.1/3) as follows:
+
+ * {AI05-0142-4} In a function call, for each explicitly aliased parameter,
+ a check is made that the accessibility level of the master of the actual
+ object is not deeper than that [of the master of the function result]
+ {determined by the point of call (see 3.10.2)}.
+
+ [Author's question: Doesn't the immediately following AARM paragraph
+ 6.4.1(15.a.1/3) need to be changed to reflect this? It seems to be
+ implying that levels don't need to be passed for aliased parameters,
+ but that's no longer true, because we're passing them for the
+ "determined by the point of call" stuff. Perhaps other AARM paragraphs
+ also need changes (maybe in 7.6.1(13.*)?]
+
+
+[Author's question: Does 6.5(8/3) need to be modified somehow to account
+for "determined by the point of call"? In version 1.6 of AI05-234, Steve
+Baird made a change to this paragraph to say "ultimate master that elaborated
+the function body". I don't see why that's necessary, but I may well be
+missing something!]
+
+
+Modify 6.5(21/3) (as modified by AI05-0051-1) as follows:
+
+ If any part {of the specific type} of the return
+ object {of a function} (or coextension thereof) [of a function] has one or
+ more access discriminants whose value is not constrained by the result
+ subtype of the function, a check is made that the accessibility level of the
+ anonymous access type of each access discriminant, as determined by the
+ expression or the return_subtype_indication [of the function] {of the return
+ statement}, is not deeper than the level of the return object as determined
+ by the point of call (see 3.10.2). If this check fails, Program_Error is
+ raised.
+
+[Author's question: The part about "of the specific type" is a change
+proposed by Steve Baird to his original wording "(ignoring the value
+of bounds and discriminants)", but I'm not sure that this quite works
+in the class-wide case. Do we need to add more wording to describe
+getting the type based on the tag in the class-wide case? Note that
+the reason for this wording is to avoid the implementation having to
+determine whether such components actually exist in the object, such
+as when there are empty arrays and inactive variant-dependent components.]
- At a given point in a program's execution, a given coextension is
- a coextension of exactly one non-coextension object. This non-coextension
- object is defined to be the "owner" of the coextension.
-
- It is possible for the master and accessibility level of an object to
- change in the following cases:
- - When an aggregate or function call result is built in place
- and one object "mutates into" another object as described in 7.6,
- the two objects may have different masters and accessibility levels.
- - When a return statement completes normally by returning from a function
- and the function result object is not built in place,
- the accessibility level of the return object changes to be
- a level determined by the point of call as described above.
- - When a coextension of one object becomes a coextension of
- a different object as described above, the master and
- accessibility level of the coextension become those of the
- new owner.
-
- Informally, the "ultimate master" of an object (or of an
- access type associated with a coextension object), is the master
- that the object will have eventually when all of these transformations
- have occurred.
-
- This is defined as follows:
-
- If the result of a function call
- or aggregate is built in place (see 7.6), the ultimate master
- of the result object is that
- of the object that the result object is used to initialize.
-
- If the result object of a function call
- is not built in place, the ultimate master
- of the result object is the master
- determined by the point of call (as described above).
-
- In the case of a function call whose result is not built
- in place, but for which coextension
- ownership will be transferred (as described above),
- the ultimate master of the coextensions
- (if any) of the result object is that of the object to
- which coextension ownership will be transferred;
- this rule is applied recursively in the case where the
- new owner is also such a function call result.
-
- AARM note:
- Informally, the ultimate master of
- a coextension is that of its "ultimate owner".
-
- In all other cases, the ultimate master of
- a coextension is that of the coextension's owner.
-
- The ultimate master of the access type of an
- allocator that creates a coextension is that
- of the coextension.
-
- For any other entity whose master is defined,
- the ultimate master of the entity is the same
- as its master.
-
-The ultimate accessibility level of an entity
-is defined to be the accessibility level of its ultimate master.
-
-AARM note:
- Despite the use of the future tense ("to which coextension
- ownership will be transferred") and words like
- "eventually" and "ultimate", implementers do not require
- a crystal ball. An additional implicit parameter may be needed
- in some cases in order to communicate information known at a
- function's call site to the callee.
-
- The terms "ultimate master" and "ultimate accessibility level" play
- no role in the static semantics of the language. In particular, they
- play no role in any accessibility-related legality rules. These terms
- define properties of an object, not of a view of an object.
-
-Add at the end of the "Dynamic Semantics" section of 4.3.1:
-
- If the type of the aggregate is discriminated and has
- default expressions for its discriminants and has
- one or more access discriminants for which the
- aggregate provides an expression (as opposed to a
- record_component_association with <>), then a check is
- made that the accessibility level of the anonymous access type of
- each such access discriminant, as determined by the expression provided
- in the aggregate, is not deeper than the ultimate accessibility level
- of the anonymous object created for the evaluation
- of the aggregate. If this check fails, Program_Error is raised.
-
- AARM note:
- This check is guaranteed to pass in the (usual) case that
- the aggregate's anonymous result object's accessibility
- level matches its ultimate accessibility level.
- An aggregate cannot contain a reference to something
- shorter-lived than itself unless the aggregate object's
- accessibility level changes, and such a pending change would
- be reflected in the ultimate accessibility level of the object.
- Note also that only a limited type may have a defaulted
- access discriminant, so this rule has no effect unless the
- type of the aggregate is limited.
-
-
-Modify 4.8(10.1/3) as (modified by AI05-0024-1 and AI05-0051-1) as
-follows (splitting it into three paragraphs):
-
- For any allocator, if the designated type of the type of the
- allocator is class-wide, then a check is made that the master
- of the type determined by the subtype_indication, or by the
- tag of the value of the qualified_expression, includes
- the elaboration of the {ultimate master of the} type of the
- allocator.
- If the subtype determined by the subtype_indication or
- qualified_expression {(or by the tag of the value of the
- qualified expression if the type of the qualified expression is
- class-wide)} of the allocator has one or more access discriminants,
- then a check is made that the accessibility level of the anonymous
- access type of each access discriminant is not deeper than [that]
- {the ultimate accessibility level} of the type of the allocator.
-
- Program_Error is raised if either such check fails.
-
-In 6.5(8) replace
-
- A check is made that the master of the type identified by the tag of the
- result includes the elaboration of the master that elaborated the function
- body.
+Add a (massive) AARM note after 6.5(21/3):
-with
+ For a function with a class-wide result type, the access values that
+ need to be checked are determined by the tag of the return object.
+ In order to implement this accessibility check in the case where
+ the tag of the result is not known statically at the point of the
+ return statement, an implementation may need to somehow
+ associate with the tag of a specific tagged
+ type an indication of whether the type has unconstrained access
+ discriminants (explicit or inherited) or has any subcomponents
+ with such discriminants. If an implementation is already maintaining
+ a statically initialized descriptor of some kind for each specific
+ tagged type, then an additional Boolean could be added to this
+ descriptor.
+
+ Note that the flag should only be queried in the case where any
+ access discriminants which the result object might have would
+ have subtypes with "bad" accessibility levels (as determined by
+ the rules of 3.10.2 for determining the accessibility level of
+ the type of an access discriminant in the expression or
+ return_subtype_indication of a return statement).
- A check is made that the master of the type identified by the tag of the
- result includes the elaboration of the ultimate master of the return object.
+ Thus, in a case like
-====
+ type Global is access T'Class;
+ function F (Ptr : Global) return T'Class is
+ begin
+ return Ptr.all;
+ end F;
+ there is no need for a run-time accessibility check. The setting
+ of the bit doesn't matter and there is no need to query it.
-Modify 6.5(21) (as modified by AI05-0051) as follows:
+ On the other hand, given
- If [any part of] the return object (or coextension
- thereof) of a function has one or more [unconstrained] access
- discriminants whose value is not constrained by the result subtype of
- the function, a check is made that the accessibility level of the
- anonymous access type of each access discriminant, as determined by
- the expression or the return_subtype_indication of the function, is
- not deeper than the [level of the return object as determined by the
- point of call]{ultimate accessibility level of the
- return object} (see 3.10.2). If this check fails, Program_Error is
- raised.
-
-[Editor's note: Steve referenced 7.6 instead on 3.10.2 here. But that makes
-no sense, the "ultimate accessibility level" is defined in 3.10.2, so
-we reference there.]
-
-[Author's Note: The new 4.3.1 wording plugs the holes associated with
-defaulted access discriminants for limited types, thereby eliminating the
-need for the "any part of" wording in 6.5(21).]
-
-[Author's Note: AI05-0051's wording changes for this paragraph includes
-adding
- "whose value is not constrained by the result subtype of the function" .
-What does this wording mean if the result subtype is
-Some_Constrained_Subtype'Class? Like a zombie, AI05-0057 refuses to
-stay buried. [Editor's comment: The same thing that it means anywhere
-else -- which we can't agree on. I don't see anything different here.]]
+ function F return T'Class is
+ Local : T'Class := ... ;
+ begin
+ return Local;
+ end F;
+ In this case, a check would typically be required.
-!discussion
+ The need for including subcomponents in this check is illustrated by
+ the following example:
-This Ai addresses two separate problems.
+ X : aliased Integer;
-1) An issue described in the !question section
- having to do with runtime accessibility checks
- for discriminants in cases involving classwide
- types where the existence of the discriminant
- is not known statically. This issue is illustrated
- by the Cw_Alloc and Cw_Return examples in
- the !example section.
-
- This turns out to be the smaller part of this AI.
-
-2) The general problem of runtime accessibilty checks for
- objects whose masters and accessibility levels are not
- constant. In the cases where a runtime accessibility check
- is performed to ensure that some entity is at least as long-lived
- as some object, the check should be performed not against the
- current accessibility level of the object, but against the
- accessibility level that the object will (or at least may)
- eventually end up with. To handle this case, the terms
- "ultimate master" and "ultimate accessibility level" are
- defined.
-
- There were previously no runtime accessibility checks associated
- with the access discriminant values specified for an aggregate.
- It might seem that an aggregate cannot possibly refer to anything
- shorter-lived than itself, so there is no need for any such check.
- There are, however, ways (described in the AI) that an aggregate's
- lifetime may be extended, which introduces the need for such a check.
- This issue is illustrated by the Agg_Check example in the
- !example section.
-
- One could view this problem as a consequence of introducing
- defaulted access discriminants for limited types. This introduces
- the need to either check aggregates (the approach taken in
- this version of the AI) or somehow check arbitrarily deeply nested
- subcomponents at the point of a function return (the approach
- taken by the previous version of this AI).
-
- We don't want to repeat checks at the point where an
- object's accessibility level changes; we want to perform
- the checks against the correct accessibility level in the
- first place so that checks are performed while we still have
- useful info about both of whatever pair of accessibility levels
- are being compared.
-
- This means that we have to know the "ultimate
- accessibility level" of the aggregate result object
- at the point where the discriminant value is given.
- It seems that this is implementable using the approach outlined
- in AI05-0051, but this needs to be confirmed. In particular,
- we need to look at combinations such as a non-build-in-place
- function call used to initialize an allocator where the
- function result owns a coextension, etc.
-
- Having defined "ultimate master" and "ultimate accessibility level"
- for use with aggregates, we may as ell use it elsewhere (see the
- second change to 6.5(21)) even if the only holes that this fixes
- are related to coextensions (and are therefore less important, at
- least to some folks).
+ type Component_Type (Discrim : access Integer := X'Access)
+ is limited null record;
-!example
+ type Undiscriminated is record
+ Fld : Component_Type;
+ end record;
- with Text_IO;
+ function F return Undiscriminated is
+ Local : aliaed Integer;
+ begin
+ return X : Untagged := (Fld => (Discrim => Local'Access)) do
+ Foo;
+ end return;
+ -- raises Program_Error after calling Foo.
+ end F;
+
+ Ramification:
+ In the case where the tag of the result is not known statically
+ at the point of the return statement and the run-time accessibility
+ check is needed, discriminant values and array bounds
+ play no role in performing this check. That is, array components are
+ assumed to have nonzero length and components declared
+ within variant parts are assumed to be present Thus, the check
+ may be implemented simply by testing the aforementioned descriptor
+ bit and conditionally raising Program_Error.
+
+!discussion
+
+The language already specifies accessibility checks for access discriminants in
+the case of allocators (to ensure that discriminant values refer do not refer to
+something that is shorter-lived than the access type) and for function results
+(to ensure that discriminant values do not refer to something that is
+shorter-lived than the eventual destination of the function result, as
+determined by the point of call).
+
+In the case where the designated type of an access type is classwide, say
+T'Class, it needs to be made clear that this check is based on the tag of the
+allocated object. A check may be required even if, for example, T is
+undiscriminated.
+
+In the case where a function result type is classwide, a similar check is
+needed. The problem is illustrated by the following two examples:
+
procedure Cw_Alloc is
type Root is tagged null record;
type Ref is access Root'Class;
- type Extension (Discrim : access Integer) is
- new Root with null record;
+
+ type Extension (Discrim : access Integer)
+ is new Root with null record;
function Bad_News return Ref is
- Local_Int : aliased Integer := 123;
- Local_Ext : aliased Extension (Discrim => Local_Int'access);
- type Local_Ref is access all Root'Class;
- for Local_Ref'Storage_Size use 0;
- Local_Ptr : Local_Ref := Local_Ext'access;
+ Local_Int : aliased Integer := 123;
+ Local_Ext : aliased Extension (Discrim => Local_Int'Access);
+ type Local_Ref is access all Root'Class;
+ for Local_Ref'Storage_Size use 0;
+ Local_Ptr : Local_Ref := Local_Ext'Access;
begin
- return new Root'Class'(Local_Ptr.all);
- -- allocator should fail, but RM 4.8(10) doesn't capture this
- -- correctly (with or without the changes of AI05-0051)
+ return new Root'Class'(Local_Ptr.all);
+ -- fails accessibility check? (yes)
end Bad_News;
Ptr : Ref := Bad_News;
- procedure Do_Nothing is
- begin
- null;
- end Do_Nothing;
begin
- Text_IO.Put_Line
- ("*** Test failed - an exception should have been raised");
- Text_IO.Put_Line
- (" Ptr.Discrim.all =" &
- Integer'Image (Extension (Ptr.all).Discrim.all));
- Do_Nothing;
- Text_IO.Put_Line
- (" Ptr.Discrim.all =" &
- Integer'Image (Extension (Ptr.all).Discrim.all));
+ -- If we reach this point, Ptr.Discrim is a dangling reference
+ ...
end Cw_Alloc;
-
- with Text_IO;
procedure Cw_Return is
type Root is tagged null record;
- type Extension (Discrim : access Integer) is
- new Root with null record;
+ type Extension (Discrim : access Integer)
+ is new Root with null record;
+
function Bad_News return Root'Class is
- Local_Int : aliased Integer := 123;
- Local_Ext : aliased Extension (Discrim => Local_Int'access);
- type Local_Ref is access all Root'Class;
- for Local_Ref'Storage_Size use 0;
- Local_Ptr : Local_Ref := Local_Ext'access;
+ Local_Int : aliased Integer := 123;
+ Local_Ext : aliased Extension (Discrim => Local_Int'Access);
+ type Local_Ref is access all Root'Class;
+ for Local_Ref'Storage_Size use 0;
+ Local_Ptr : Local_Ref := Local_Ext'Access;
begin
return Local_Ptr.all;
- -- return should fail, but RM 6.5(21) doesn't capture this
- -- correctly (with or without the changes of AI05-0051)
+ -- fails accessibility check? (yes)
end Bad_News;
+
Obj : Root'Class := Bad_News;
+
begin
- Text_IO.Put_Line
- ("*** Test failed - an exception should have been raised");
- Text_IO.Put_Line
- (" Obj.Discrim.all =" &
- Integer'Image (Extension (Obj).Discrim.all));
+ -- If we reach this point, Obj.Discrim is a dangling reference
+ ...
end Cw_Return;
+In addition, these checks also need to be generalized to handle the case of a
+subcomponent which has defaulted access discriminant values, as in
- procedure Agg_Check is
- type Subcomponent_Type (Discrim : access Integer := null)
- is limited null record;
- type Component_Type is
- record
- S : Subcomponent_Type;
- end record;
- type Rec is
- record
- Fld : Component_Type;
- end record;
- type Ref1 is access Rec;
- Ptr1 : Ref1;
-
- procedure Nested is
- type Ref2 is access Rec;
- Ptr2 : Ref2;
+ X : aliased Integer;
- Local : aliased Integer;
+ type Subcomponent_Type (Discrim : access Integer := X'Access)
+ is limited null record;
- function F return Rec is
- begin
- return (Fld => (S => (Discrim => Local'access)));
- end F;
+ type Component_Type is record S : Subcomponent_Type; end record;
- Ptr2 := new Rec'(F); -- ok
- Ptr1 := new Rec'(F); -- fails accessibility check
- begin
- Nested;
- end Agg_Check;
+ type Undiscriminated is record
+ Fld : Component_Type;
+ end record;
+
+ function F return Undiscriminated is
+ Local : aliaed Integer;
+ begin
+ return X : Untagged
+ := (Fld => (S => (Discrim => Local'Access))) do
+ Foo;
+ end return;
+ -- raises Program_Error after calling Foo.
+ end F;
+
+!example
+
!ACATS Test
Add an ACATS C-Test to check that the exception is raised in examples like the
@@ -2193,13 +2184,71 @@
Sent: Wednesday, February 16, 2011 2:51 PM
> Steve Baird:
-> * AI05-0234-1 Add missing wording, consider class-wide coextension
+> * AI05-0234-1 Add missing wording, consider class-wide coextension
> cases. [Need !discussion
Here is a !discussion and !example section for AI05-0234 The Agg_Check example
is new; the other two examples are taken from the previous version of the AI.
[Editor's note: This is version /03 of the AI.]
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, March 16, 2011 12:49 AM
+
+Here's a preliminary revision of AI05-234 (the son of AI05-51). [This is
+version /04 of the AI - Editor.] This is
+an update of the !wording, based on the earlier cvs version 1.4. At the last
+ARG meeting it was decided that rather than introducing new terms 'ultimate
+master' and 'ultimate accessibility level' as proposed by Steve in version 1.6,
+that instead we should define 'determined by the point of call', a phrasing
+already used in several places (mostly due to the changes of AI05-51).
+
+So the bulk of the change here is the addition of a set of bulleted paragraphs
+in 3.10.2 that attempts to give a consolidated definition of 'determined by
+point of call'. Some of these bullets were extracted from the sentences in
+3.10.2(14.5/3), which was added by AI05-51. Various other smaller wording
+changes are included, a number of which were identified at the last meeting.
+
+I say 'preliminary' above because I'm still trying to sort out some details,
+and still hoping to make some more progress on that tomorrow. In a few places
+I've inserted some questions for pieces that are missing or may have an issue
+that needs addressing. One specific missing piece that I confess is a gap
+at this point is the treatment of coextensions. I also haven't updated the
+!discussion, and that might need further work. It's also possible that I've
+screwed things up here, in which case preliminary may be an understatement. :)
+
+Comments from anyone who has the time outside of working on their own homework
+to take a look at this would be greatly appreciated. (Thanks to Steve for
+offering some chunks of time to discuss this last week during my struggles
+to come to grips with this one after he most generously unloaded it on me.
+I'll probably be bending his ear a little further tomorrow...)
+
+BTW, sort of a side question I'd like an answer to that isn't included below
+in the AI is about a paragraph in the !wording of AI05-51 that doesn't appear
+to have made it into the online RM. The paragraph defines the statically
+deeper relationship for the case of an anonymous access result. I'd like
+to know if that's an oversight or was it decided at some point that it was
+wrong or unneeded (but it looks like it was an oversight).
+
+In AI05-51 (both !wording and !corrigendum) it says:
+
+ Add after 3.10.2(19/2):
+
+ * For determining whether a level is statically deeper than the level of the
+ anonymous access type of an access result of a function, when within a
+ return statement that applies to the function, the level determined by the
+ point of call is presumed to be the same as that of the level of the master
+ that elaborated the function body.
+
+If this was supposed to be added, then it would probably make sense to
+correct the oversight in AI05-234.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, March 16, 2011 12:49 AM
****************************************************************
Questions? Ask the ACAA Technical Agent