Version 1.1 of acs/ac-00140.txt

Unformatted version of acs/ac-00140.txt version 1.1
Other versions for file acs/ac-00140.txt

!standard 13.10(3)          07-02-16 AC95-00140/01
!class confirmation 07-02-16
!status received no action 07-02-16
!status received 07-01-22
!subject What is the accessibility of 'Unchecked_Access?
!summary
!appendix

From: Pascal Leroy
Date: Monday, January 22, 2007 10:11 AM

I am looking at a case where the Ada 2005 accessibility rules seem to
introduce an unanticipated incompatibility.  Consider the following code
fragment, excerpted from real customer code:

    type T (D : access Integer) is limited null record;
    type A is access T;

    procedure P is
       X : aliased Integer;
       Y : A := new T (X'Unchecked_Access); -- LEGAL?
    begin
       null;
    end P;

My compiler rejects the allocator, citing 4.8(5.2/2), which reads:

"If the designated subtype of the type of the allocator has one or more
unconstrained access discriminants, then the accessibility level of the
anonymous access type of each access discriminant, as determined by the
subtype_indication or qualified_expression of the allocator, shall not be
statically deeper than that of the type of the allocator (see 3.10.2)."

Now what is the accessibility level of the anonymous type of the access
discriminant D in this case?  The applicable rule is 3.10.2(12.1/2) which
reads:

"If the value of the access discriminant is determined by a
discriminant_association in a subtype_indication, the accessibility level
of the object or subprogram designated by the associated value (or library
level if the value is null);"

Now the accessibility level of the object designated by X'Unchecked_Access
is that of X, and so the accessibility level of the access discriminant in
the allocator is that of X, which is deeper than A, the type of the
allocator, so the allocator is illegal.

I am aware of the rule in 13.10(3) which says that the "rules and
semantics that apply to X'Access (see 3.10.2) apply also to
X'Unchecked_Access, except that, for the purposes of accessibility rules
and checks, it is as if X were declared immediately within a library
package".  However, this doesn't help because 3.10.2(12.1/2) is *not* a
rule that applies to attribute Access.

It seems to me that we need an extra rule in 3.10.2(12.1/2) (or 13.10?) to
say that, if the designated object is obtained by an Unchecked_Access
attribute, it is assumed to be at library level.

****************************************************************

From: Tucker Taft
Date: Monday, January 22, 2007 10:28 AM

Good catch.  I would say both 3.10.2(12.1/2) and 3.10.2(12.2/2)
should say "(or library level if null or the result of an
Unchecked_Access attribute_reference)".

****************************************************************

From: Robert A. Duff
Date: Monday, January 22, 2007  5:11 PM

I agree.

****************************************************************

From: Randy Brukardt
Date: Monday, January 22, 2007  8:30 PM

...
> Good catch.  I would say both 3.10.2(12.1/2) and 3.10.2(12.2/2)
> should say "(or library level if null or the result of an
> Unchecked_Access attribute_reference)".

Humm. Are we sure that this is the only point at which the accessibility of
a value created by 'Unchecked_Access is used? If not, wouldn't it be better
to simply define the accessibility of "the result of an Unchecked_Access
attribute reference" to be library level? Then we'd be much less likely to
have this sort of problem crop up again.

Pascal had said:

> I am aware of the rule in 13.10(3) which says that the "rules and
> semantics that apply to X'Access (see 3.10.2) apply also to
> X'Unchecked_Access, except that, for the purposes of accessibility rules
> and checks, it is as if X were declared immediately within a library
> package".  However, this doesn't help because 3.10.2(12.1/2) is *not* a
> rule that applies to attribute Access.

But there are a lot of rules that don't apply to attribute 'Access. Either,
this interpretation of 13.10(3) is too narrow, or we have a lot of potential
for trouble (not just discriminant checks). We know that this wording has to
prevent the 'Unchecked_Access attribute from making accessibility checks.
But what about the value created by the attribute. Pascal's interpretation
surely does not apply to uses of access parameters (which when used inside a
subprogram surely have nothing to do with 'Access). Consider a type
conversion of an access parameter to another access type. This is an
accessibility check, but it's not one that applies to the attribute access.
Pascal is saying that for the purposes of this check, the access parameter
(when the actual is 'Unchecked_Access), doesn't have library level. That way
leads to madness.

So, it seems to me that either (a) there is nothing wrong here, and Pascal
is mistaken, or (b) there is a big problem here, that needs an immediate
fix. I actually lean toward (b), because the wording seems to be
unnecessarily obtuse. I surely don't want to go around adding "of the result
of an 'Unchecked_Access attribute" everywhere. Heck, I don't think that is
even right: what if the unchecked_access attribute is passed as an access
parameter, and then it is used as an access discriminant? You would still
have to make the check.

So I would just add "The accessibility of the object designated by the
result of an Unchecked_Access attribute reference is assumed to be library
level." (or something like that) to an appropriate place. This would fit
best in 3.10.2, but I know we wanted to avoid referencing Unchecked_Access
there (else we wouldn't have the "hidden" wording in 13.10; it would just be
defined in 3.10.2). So maybe it should go in 13.10.

****************************************************************

From: Tucker Taft
Date: Monday, January 22, 2007  8:56 PM

I guess I agree with Randy.  It would be better to fix
13.10 rather than further complicate 3.10.2 (if that is
actually humanly possible ;-).  In looking further
at 13.10, I'm not convinced we need to do anything.
It already says that for the purpose of accessibility rules
(which certainly covers 3.10.2(12*)), X'Unchecked_Access is
nearly equivalent to X'Access, except that X is treated as
though it is library level.  I believe that pretty much
covers 12.1 and 12.2, since they refer to the "accessibility
level of the object or subprogram designated by the value"
and if that value is X'Unchecked_Access, then the object
or subprogram X is considered to be library level.

So we could add an AARM note I suppose, but as far as
official wording, I think we are already covered.

****************************************************************

From: Randy Brukardt
Date: Monday, January 22, 2007  9:12 PM

If that's the conclusion, I don't even see the need for an AARM note (other
than to convince confused implementers ;-). This interpretation of this rule
is needed in Ada 95, too.

Since I worked out this Ada 95 example, I figured I'd share it:

    type T is ...
    type A is access all T;

    An_A : A;

    procedure Check_It (P : access T) is
    begin
        An_A := A(P); -- A run-time accessibility check here.
    end Check_It;

    procedure Use_It is
        Obj : aliased T;
    begin
        Check_It (Obj'Unchecked_Access); -- Better not raise Constraint_Error!
        An_A := null; -- So we don't have a dangling pointer.
        Check_It (Obj'Access); -- Better raise Constraint_Error.
    end Use_It;

    Use_It;

****************************************************************

From: Pascal Leroy
Date: Tuesday, January 23, 2007  1:24 AM

> In looking further at 13.10,
> I'm not convinced we need to do anything. It already says
> that for the purpose of accessibility rules (which certainly
> covers 3.10.2(12*)), X'Unchecked_Access is nearly equivalent
> to X'Access, except that X is treated as though it is library
> level.  I believe that pretty much covers 12.1 and 12.2,
> since they refer to the "accessibility level of the object or
> subprogram designated by the value" and if that value is
> X'Unchecked_Access, then the object or subprogram X is
> considered to be library level.

I disagree with this reasoning.  The object designated by X'Access is the
same as the object designated by X'Unchecked_Access (it's X, duh).  What
13.10 is saying is that, for the purposes of checking the legality of
X'Unchecked_Access, X is assumed to be at library-level.  It doesn't say
that the resulting access value carries an accessibility level
corresponding to the library level.  Obviously it should, so I agree that
the right place for a fix is 13.10.  But we cannot just read between the
lines: this should be stated explicitly.

****************************************************************

From: Tucker Taft
Date: Tuesday, January 23, 2007  2:28 AM

> I disagree with this reasoning.  The object designated by X'Access is the
> same as the object designated by X'Unchecked_Access (it's X, duh).  What
> 13.10 is saying is that, for the purposes of checking the legality of
> X'Unchecked_Access, X is assumed to be at library-level.

It isn't just for checks that X is assumed to be library-level.
It is also assumed to be library-level for the purposes of
"accessibility rules" which in my view includes all of the rules
in 3.10.2.

 > ...  It doesn't say
> that the resulting access value carries an accessibility level
> corresponding to the library level.

Wow, we clearly have different interpretations of the point of
this paragraph.  We rely on this in Ada 95 for the following (3.10.2(13)):

    The accessibility level of the anonymous access type of an access
    parameter is the same as that of the view designated by the actual.

That combined with 13.10 to me means that X'Unchecked_Access delivers
up the "library level" as its accessibility level when used as the
actual for an access parameter.  You seem to be implying that
13.10 is only used for the purposes of the legality rules and
run-time checks in 3.10.2(28-29).  I have never interpreted 13.10
that narrowly.

> ... Obviously it should, so I agree that
> the right place for a fix is 13.10.  But we cannot just read between the
> lines: this should be stated explicitly.

I think you are reading 13.10 more narrowly than was
required for sensible use of 'Unchecked_Access in Ada 95.

In any case, if you want to suggest some wording to add
to 13.10, great.  But I think it is important to realize
this is really an Ada 95 fix, not an Ada 2005 fix.

****************************************************************

From: Randy Brukardt
Date: Tuesday, January 23, 2007  12:45 PM

> It isn't just for checks that X is assumed to be library-level.
> It is also assumed to be library-level for the purposes of
> "accessibility rules" which in my view includes all of the rules
> in 3.10.2.

Well, that's one way to read it. But the prefix of the statement is "all the
rules that apply to X'Access", and then we have an "except". It's hard to
see how an "except" can be expansive beyond what it applies to, and that is
just the rules that apply to X'Access.

>  > ...  It doesn't say
> > that the resulting access value carries an accessibility level
> > corresponding to the library level.
>
> Wow, we clearly have different interpretations of the point of
> this paragraph.  We rely on this in Ada 95 for the following (3.10.2(13)):
>
>     The accessibility level of the anonymous access type of an access
>     parameter is the same as that of the view designated by the actual.
>
> That combined with 13.10 to me means that X'Unchecked_Access delivers
> up the "library level" as its accessibility level when used as the
> actual for an access parameter.  You seem to be implying that
> 13.10 is only used for the purposes of the legality rules and
> run-time checks in 3.10.2(28-29).  I have never interpreted 13.10
> that narrowly.

I gave an example of this yesterday.

Well, that's what it says, and Pascal certainly can interpret it that way. I
personally think that interpretation fails the Dewar rule (it is absurd, so
the RM clearly doesn't say that). But that just means that the wording needs
to be improved.

> > ... Obviously it should, so I agree that
> > the right place for a fix is 13.10.  But we cannot just read between the
> > lines: this should be stated explicitly.
>
> I think you are reading 13.10 more narrowly than was
> required for sensible use of 'Unchecked_Access in Ada 95.

That's true, but it should be noted that there is no C-Test for
'Unchecked_Access in the ACATS. So there is nothing really to make
implementers do something sensible.

What Pascal hasn't said is what his compiler does with my example from
yesterday. My guess is that it would not raise Program_Error (I mistakenly
said Constraint_Error in the example, sorry).  If that's so, his position is
inconsistent and we just need to clean up the wording a bit at a low
priority. If his compiler does raise Program_Error, then we have a bigger
problem, because we'd have a real difference of opinion on the intent.

> In any case, if you want to suggest some wording to add
> to 13.10, great.  But I think it is important to realize
> this is really an Ada 95 fix, not an Ada 2005 fix.

Right, this have nothing whatsoever to do with Ada 2005. The wording of
13.10 has always confused people and it should be fixed. Note that Adam
Beneschan tried to ask essentially this same question in May 2003 (see
AC-0053), but he got so confused by 3.10.2 that he withdrew the question
before anyone other than Gary commented on it. (If he had hit on the example
that I showed yesterday, we may have dealt with this in the Amendment.) And
Gary's "That seems fairly clear from the RM wording." response does not
engender confidence that the wording is right.

****************************************************************

From: Pascal Leroy
Date: Wednesday, January 24, 2007  1:12 AM

> > It isn't just for checks that X is assumed to be library-level. It is
> > also assumed to be library-level for the purposes of "accessibility
> > rules" which in my view includes all of the rules in 3.10.2.
>
> Well, that's one way to read it. But the prefix of the
> statement is "all the rules that apply to X'Access", and then
> we have an "except". It's hard to see how an "except" can be
> expansive beyond what it applies to, and that is just the
> rules that apply to X'Access.

My point exactly.  13.10(3) applies to the rules related to X'Access, not
to any random rule in the RM that talks about access values or
accessibility.  I agree that it violates the Dewar Rule, but I am asking
that the words be improved/corrected.

> What Pascal hasn't said is what his compiler does with my
> example from yesterday. My guess is that it would not raise
> Program_Error (I mistakenly said Constraint_Error in the
> example, sorry).

Good guess, Randy, we do not raise P_E on the accessibility check for
Unchecked_Access.

> If that's so, his position is inconsistent
> and we just need to clean up the wording a bit at a low
> priority.

My original message was about *statically rejecting* a piece of code (an
allocator constrained by Unchecked_Access).  I was not claiming that this
rejection was correct, but I was (and still am) claiming that if you
slavishly implement the words of the RM, as I did, you have to reject this
code.  I was lucky that this construct did appear in some customer code,
otherwise I would never have noticed the problem.  If I was confused by
this, and if Adam was confused in 2003, perhaps others might be confused
too, so we should fix the wording rather than depend on Tuck's creative
reading or on the Dewar Rule.

****************************************************************

From: Tucker Taft
Date: Wednesday, January 24, 2007  7:35 AM

OK, we seem to agree this is an Ada 95 wording problem in 13.10,
which was perhaps exacerbated in Ada 2005 due to increasing
complexity of accessibility rules.  So here is a first
attempt at rewording 13.10:

   X'Unchecked_Access

      All rules and semantics that apply to X'Access (see 3.10.2)
      apply also to X'Unchecked_Access, except that, for the purposes
      of accessibility rules and checks, it is as if X were declared
      immediately within a library package.  {Similarly, for the
      purposes of rules that define the accessibility level of an
      anonymous access type, the view designated by an access value
      specified by an Unchecked_Access attribute_reference is of library
      level.}

Does that eliminate the confusion?

****************************************************************

From: Pascal Leroy
Date: Wednesday, January 24, 2007 11:19 AM

Fine with me.

****************************************************************

From: Randy Brukardt
Date: Wednesday, January 24, 2007  2:08 PM

And fine with me, too.

But I don't see how it can be fine with Pascal. He said earlier:

> My original message was about *statically rejecting* a piece of code (an
> allocator constrained by Unchecked_Access).  I was not claiming that this
> rejection was correct, but I was (and still am) claiming that if you
> slavishly implement the words of the RM, as I did, you have to reject this
> code.

The problem is, Tucker's proposal doesn't change anything having to do with
static rejection. So, if Pascal feels it was wrong before, then it still is
wrong.

But I don't quite see what is wrong. The wording says "rules AND SEMANTICS",
which means that the semantics of X'Unchecked_Access are also covered.
Surely, that includes how X'Unchecked_Access is used. (I missed the word
"semantics" yesterday, but it is there.) So I don't see Pascal's original
problem - it says that the semantics of X'Unchecked_Access is as if X is
declared at library level, and surely the rule in question is an
accessibility check. So it would seem to be covered by the original wording.

****************************************************************

From: Tullio Vardanega
Date: Wednesday, January 24, 2007  3:54 PM

A very interesting discussion and a very neat piece of text
that clarifies it all even to me.

****************************************************************

From: Pascal Leroy
Date: Thursday, January 25, 2007  4:37 AM

It's OK with me if you want to put the sentence that Tuck added in
redundant brackets.

****************************************************************

Editor's note: Pascal told me in private mail on February 5th
that he would be satisfied with beefing up the AARM notes
in 13.10(3), 3.10.2(3), and 3.10.2(12). This was added to AI05-0005.

****************************************************************

Questions? Ask the ACAA Technical Agent