CVS difference for ai05s/ai05-0234-1.txt
--- ai05s/ai05-0234-1.txt 2011/04/30 07:28:36 1.12
+++ ai05s/ai05-0234-1.txt 2011/06/04 03:43:11 1.13
@@ -1,5 +1,14 @@
-!standard 6.5(21/3) 11-04-07 AI05-0234-1/06
+!standard 3.10.2(10/2) 11-06-03 AI05-0234-1/07
+!standard 3.10.2(12.1/2)
+!standard 3.10.2(14.4/2)
+!standard 3.10.2(19/2)
+!standard 4.8(10.1/2)
+!standard 6.4.1(6)
+!standard 6.4.1(15)
+!standard 6.5(21/2)
!class binding interpretation 10-11-15
+!status Amendment 2012 11-06-03
+!status ARG Approved (by Letter Ballot) 11-0-0 11-05-16
!status work item 10-11-15
!status received 10-10-31
!priority Low
@@ -94,19 +103,19 @@
Change 3.10.2(10/2):
- 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.
+ * 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 address 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.
+ * 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):
@@ -137,16 +146,15 @@
+ In other cases, the master of the call 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 of this choice in terms of masters,
- lifetimes, and accessibility is transparent to the program.
+ [AARM] Ramification: These rules do not mention whether the result object is
+ built-in-place (see 7.6). In particular, in the case where building in place is optional,
+ the choice whether or not to build-in-place has no effect on masters,
+ lifetimes, or accessibility.
[AARM] Implementation Note: There are several cases where the implementation
may have to pass in the accessibility level of the result object on a call,
to support later rules where the accessibility level comes from the master
- of the call.
+ of the call:
* when the function result may have a part with access discriminants;
@@ -166,8 +174,8 @@
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
+ expression in the declaration of the discriminant, 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
@@ -208,16 +216,22 @@
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
+ of the allocator {(or by the tag of the value if the type of the
+ qualified_expression is class-wide)} 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(6.3/3) as follows:
+
+In a function call, the accessibility level of the actual object
+for each explicitly aliased parameter shall not be statically deeper than
+accessibility level of the master of the [function result]{call (see 3.10.2)}.
+
Modify 6.4.1(15.1/3) as follows:
- * {AI05-0142-4} In a function call, for each explicitly aliased parameter,
+ * 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]
{call (see 3.10.2)}.
@@ -240,8 +254,8 @@
implementation. In the case of class-wide result objects this allows
the testing of a simple flag in the tagged type descriptor that indicates
whether specific type has any parts with access discriminants. By basing
- the test on the object's type rather than the object itself, we avoid
- concerns about the whether subcomponents of arrays (which might be empty)
+ the test on the type of the object rather than the object itself, we avoid
+ concerns about whether subcomponents of arrays (which might be empty)
and in variant parts are present.
Add a (massive) AARM note after 6.5(21/3):
@@ -260,10 +274,10 @@
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
+ access discriminants which the result object might have subtypes
+ with "bad" accessibility levels (as determined by the rules of
+ 3.10.2 for determining the accessibility level of the type of
+ of an access discriminant in the expression or
return_subtype_indication of a return statement).
Thus, in a case like
@@ -425,6 +439,167 @@
!example
+!corrigendum 3.10.2(10/2)
+
+@drepl
+@xbullet<The accessibility level of an @fa<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 @fa<aggregate> or
+the result of a function call is that of the innermost master that evaluates
+the @fa<aggregate> or function call.>
+@dby
+@xbullet<The accessibility level of an @fa<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 @fa<aggregate> is that of the
+innermost master that evaluates the @fa<aggregate>.>
+
+@xbullet<The accessibility level of the result of a function call is
+that of the @i<master of the function call>, which
+is determined by the point of call as follows:>
+
+@xinbull<If the result is used (in its entirety) to directly initialize part of an
+object, the master is that of the object being initialized.
+In the case where the initialized object is a coextension that becomes
+a coextension of another object (see below), the master is
+that of the eventual object to which the coextension will be
+transferred.>
+
+@xinbull<If the result is of an anonymous access type and is the operand of an
+explicit conversion, the master is that of the target type of the conversion;>
+
+@xinbull<If the result is of an anonymous access type and defines an access
+discriminant, the master is the same as that for an object
+created by an anonymous @fa<allocator> that defines an access discriminant
+(even if the access result is of an access-to-subprogram type).>
+
+@xinbull<If the call itself defines the result of a function to which one of
+the above rules applies, these rules are applied recursively;>
+
+@xinbull<In other cases, the master of the call is that of the
+innermost master that evaluates the function call.>
+
+!corrigendum 3.10.2(12.1/2)
+
+@dinsa
+@xinbull<If the value of the access discriminant is determined by a
+@fa<discriminant_association> in a @fa<subtype_indication>, the accessibility level
+of the object or subprogram designated by the associated value (or library level if
+the value is null);>
+@dinst
+@xinbull<If the value of the access discriminant is determined by a
+@fa<default_expression> in the declaration of the discriminant, the level of the
+object or subprogram designated by the associated value (or library level
+if null);>
+
+!corrigendum 3.10.2(14.4/2)
+
+@dinsa
+@xindent<In this last case, the allocated object
+is said to be a @i<coextension> of the object whose discriminant designates it,
+as well as of any object of which the discriminated object is itself a
+coextension or subcomponent. All coextensions of an object are finalized when
+the object is finalized (see 7.6.1).>
+@dinst
+@xbullet<Within a return statement, the accessibility level of the
+anonymous access type of an access result is that of the master of the call.>
+
+!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<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 of the master of the call is presumed to be the same
+as that of the level of the master that elaborated the function
+body.>
+
+!corrigendum 4.8(10.1/2)
+
+@drepl
+For any @fa<allocator>, if the
+designated type of the type of the @fa<allocator> is class-wide, then
+a check is made that the accessibility level of the type determined by
+the @fa<subtype_indication>, or by the tag of the value of the
+@fa<qualified_expression>, is not deeper than that
+of the type of the @fa<allocator>. If the
+designated subtype of the @fa<allocator> has one or more unconstrained
+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 @fa<allocator>.
+Program_Error is raised if either such check fails.
+@dby
+For any @fa<allocator>, if the
+designated type of the type of the @fa<allocator> is class-wide, then
+a check is made that the master of the type determined by
+the @fa<subtype_indication>, or by the tag of the value of the
+@fa<qualified_expression>, includes the elaboration
+of the type of the @fa<allocator>. If any part of the subtype determined
+by the @fa<subtype_indication> or @fa<qualified_expression>
+of the @fa<allocator> (or by the tag of the value if the type of the
+@fa<qualified_expression> is class-wide) 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 @fa<allocator>. Program_Error is raised if either such check fails.
+
+
+!corrigendum 6.4.1(6)
+
+@dinsa
+The type of the actual parameter associated with an access parameter
+shall be convertible (see 4.6) to its anonymous access type.
+@dinst
+If the formal parameter is an explicitly aliased parameter, the type of the actual
+parameter shall be tagged or the actual parameter shall be an aliased view of
+an object. Further, if the formal parameter subtype @i<F> is untagged:
+@xbullet<the subtype @i<F> shall statically match the nominal subtype of the actual
+object; or>
+@xbullet<the subtype @i<F> shall be unconstrained, discriminated in its full view,
+and unconstrained in any partial view.>
+
+In a function call, the accessibility level of the actual object
+for each explicitly aliased parameter shall not be statically deeper than
+accessibility level of the master of the call (see 3.10.2).
+
+!corrigendum 6.4.1(15)
+
+@dinsa
+@xinbull<For any other type, the formal parameter is uninitialized. If composite,
+a view conversion of the actual parameter to the nominal subtype of the formal is
+evaluated [(which might raise Constraint_Error)], and the actual subtype of the
+formal is that of the view conversion. If elementary, the actual subtype of the
+formal is given by its nominal subtype.>
+@dinst
+@xbullet<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 call (see 3.10.2).>
+
+!corrigendum 6.5(21/2)
+
+@drepl
+If the result subtype of a function has one or more unconstrained access
+discriminants, a check is made that the accessibility level of the anonymous
+access type of each access discriminant, as determined by the @fa<expression>
+or the @fa<return_subtype_indication> of the function, is not deeper than that
+of the master that elaborated the function body. If this check fails,
+Program_Error is raised.
+@dby
+If any part of the specific type of the return object of a function
+(or coextension thereof) 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 @fa<expression> or the @fa<return_subtype_indication> of the
+return statement, is not deeper than the level of the master of the
+call (see 3.10.2). If this check fails, Program_Error is raised.
+
+
!ACATS Test
Add an ACATS C-Test to check that the exception is raised in examples like the
@@ -1972,7 +2147,8 @@
Question #1 -
Are there interactions between this "ultimate" stuff and aliased paraemters?
-Do we also need to add an "ultimate" to the wording for the runtime accessibility check associated with an aliased parameter?
+Do we also need to add an "ultimate" to the wording for the runtime accessibility
+check associated with an aliased parameter?
6.4.1(15.1/3):
In a function call, for each explicitly aliased parameter, a check is
@@ -2372,6 +2548,21 @@
The purpose of this is to allow AI05-0190-1, Global storage pool
controls, to use this term.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, May 15, 2011 2:52 PM
+
+[Appropriate part of a large message - Editor.]
+
+> AI05-0234-1/06 Hole in AI05-0051-1
+> [Defines terms used in AI05-0190-1, fixes bugs in accessibility checks.]
+> Approve __X____ Disapprove ______ Abstain _______
+
+Editorial Comment:
+In AARM note after 6.5(21/3)
+ Second paragraph=> "might have would have"
****************************************************************
Questions? Ask the ACAA Technical Agent