Version 1.3 of ai12s/ai12-0038-1.txt

Unformatted version of ai12s/ai12-0038-1.txt version 1.3
Other versions for file ai12s/ai12-0038-1.txt

!standard E.2.1(7/1)          12-12-31 AI12-0038-1/02
!class binding interpretation 12-11-28
!status Amendment 202x 12-12-31
!status ARG Approved 5-0-4 12-12-09
!status work item 12-11-28
!status received 12-06-23
!priority Low
!difficulty Medium
!subject Shared_Passive package restrictions
!summary
Shared_Passive restrictions have to be adjusted because declared-pure packages now allow the declarations of access types.
!question
Shared passive packages are allowed to depend on declared-pure packages. In Ada 2005, access type declarations were allowed in declared-pure packages, but the implications of this were not accounted for in the restrictions on shared passive packages. Should we add new restrictions directly on shared passive packages to account for this change? (Yes)
!recommendation
Shared passive packages are not allowed to declare access-to-class-wide types, but there is nothing preventing them from referencing an access-to- class-wide type declared in a declared-pure package. We propose to disallow using access types declared in declared-pure packages within a shared-passive package.
!wording
Modify E.2.1(7/1):
* it shall not contain a library-level declaration of an access type that designates a class-wide type, task type, or protected type with entry_declarations{; further, it shall not contain a library-level declaration that includes a name that denotes a subtype with a part having an access type that is declared within a declared-pure package}.
!discussion
The accessibility rule of E.2.1(8) is intended to prevent pointers being created in a shared-passive package that point "back" into the data area of some particular active partition. Unfortunately, this doesn't work if the access type is declared in something other than a shared-passive package, in particular, in a declared-pure package. Therefore, we need to disallow the use of such "unprotected" access types in a shared-passive package. That is the point of the wording added to E.2.1(7/1).
!corrigendum E.2.1(7/1)
Replace the paragraph:
by:
!ACATS test
An ACATS B-Test should be created to check that the new rule is actually enforced.
!appendix

From: Tucker Taft
Sent: Thursday, November 29, 2012  8:49 AM

I was tasked with splitting off an AI from AI12-0031, to deal with issues associated
with shared-passive packages and their interaction with declared-pure packages.
The basic problem is that in Ada 2005 we starting allowing access types to be declared
in declared-pure packages, but didn't adjust the rules for shared-passive packages to
account for that change.

So here is a proposed new AI that tries to do that.

[This is version /01 of this AI.]

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

From: Randy Brukardt
Sent: Thursday, November 29, 2012  1:27 PM

...
> So here is a proposed new AI that tries to do that.

I fear the Mayans are right about an impending apocalypse, as the point when Tucker is
among the first to finish most of his homework is roughly as likely as me winning the
Powerball lottery. :-)

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

From: Randy Brukardt
Sent: Thursday, November 29, 2012  8:12 PM

The first sentence of the !discussion says:

The accessibility rule of E.2.3(8) is intended to prevent pointers being created in a
shared-passive package that poing "back" into the data area of some particular active
partition.

"poing" is a new term for Ada, even informally. :-) I presume you mean "pointing", right?

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

From: Randy Brukardt
Sent: Thursday, November 29, 2012  8:15 PM

Upon further reflection, you probably meant "point" (no "ing").

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

From: Tucker Taft
Sent: Thursday, November 29, 2012  8:16 PM

> "poing" is a new term for Ada, even informally. :-) I presume you mean
> "pointing", right?

Oops.  I meant "point".

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

From: Randy Brukardt
Sent: Monday, December 31, 2012  6:08 PM

For AI12-0038-1, we approved the following wording:

it shall not contain a library-level declaration of an access type that
designates a class-wide type, task type, or protected type with
entry_declarations{; further, it shall not contain a library-level declaration
that includes a name that denotes a subtype with a part having an access type
that is declared within a declared-pure package}.

So far so good. Then, the first draft of the minutes on the meeting go on to
say:

A non-limited private type that has stream attributes and an access component
could be legal in a declared-pure package (as the type would then have external
streaming). If the package also declares a function that is passed an access
value and returns that type could cause trouble by storing the parameter value
into the component and then returning that to be stored in an object of the
shared-passive partition. No solution is obvious: a solution would seem to
require making referencing any non-limited private types illegal which seems way
over the top. We're going to ignore this problem.

Say what?? Did we really decide this? (Probably, as 4 people abstained,
presumably because of this hole.)

The problem here is that we can't get away with completely ignoring this "hole".
If we ignore it, we're saying that compilers have to make it work. But that
makes no sense; if we're going to require it to work in some (obscure) case,
then we surely don't need E.2.1(7-8) to prevent it in most cases. Even if we
can't figure out an appropriate rule, we need to let compilers off the hook
somehow.

Specifically, we either need a Legality Rule, some sort of run-time check, or it
has to be erroneous.

A Legality Rule would be easy if we could break privacy, but we can't.
Probably the best solution would to attack the function that is required to
cause a problem (as it has to return the type, and take a parameter with a part
of an access type). But there probably are more forms of this (for instance, a
procedure with an out parameter of the type), so such a solution is likely to be
fragile.

I suppose we could have a To-Be-Honest AARM note that implementations need to
break privacy to make the check described by the wording given above. (That
seems to be OK since Mr. Private is retired. ;-) I would hope that is a last
resort, however.

A run-time check might happen here anyway (we're talking about passing an access
parameter in most of the scenarios), but adding overhead for this is not
appealing. And figuring out the interactions of E.2.1(8) and the algorithms
described for AI12-0016-1 sound like torture.

There is some argument for making it erroneous; I suspect that there are other
ways to get an access value of some other partition (via chapter 13 means, at
least), and those are probably going to be erroneous (at least we hope so!). A
small expansion isn't going to be a major problem.

Another option would be to make assigning a non-limited private type that has
part of an access type declared in a declared-pure package a bounded error
inside of a shared-passive package. Either it works (no one will want to
implement that) or it raises Program_Error. This check (being at runtime) can
break privacy, but in actual fact, it would always be detected at compile-time.
(And presumably would have an associated warning.) [Since the package is
preelaborated, a dangerous value can only be introduced by a later assignment,
as no constructor functions are allowed -- I think.] Or perhaps just do this for
the declaration of such an object at library-level in a shared passive package.

Should we reopen this AI to get *some* solution to this problem?? (I have no
idea what to write in the AI to explain why we're ignoring this hole.) Is there
any better ideas of a solution?

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

Questions? Ask the ACAA Technical Agent