!standard E.2.2 (11) 05-05-05 AI95-00431/01
!class binding interpretation 05-04-18
!status Amendment 200Y 05-05-05
!status WG9 Approved 06-06-09
!status ARG Approved 9-0-1 05-04-18
!status work item 05-04-18
!status received 05-04-18
!priority Medium
!difficulty Easy
!subject Conversions to remote access-to-subprogram types
!summary
All conversions between remote access-to-subprogram and local
access-to-subprogrmam types are forbidden.
!question
E.2.2(11) forbids the conversion of a value of a remote access-to-subprogram
(RAS) type to a local access-to-subprogram (LAS) type. But there is no rule
which prohibits the conversion of a LAS type to a RAS type. It seems that these
are likely to have totally different representations, and ACATS test BXE2011
already requires that such conversions be rejected. Are such conversions
intended? (No.)
!recommendation
(See summary.)
!wording
Change E.2.2(11) to say:
* A value of a remote access-to-subprogram type shall be converted only
to {or from} another (subtype-conformant) remote access-to-subprogram type;
!discussion
Note that this cannot be done through Var.all'Access, because E.2.2(12)
requires that the prefix of an Access attribute "statically denote" a remote
subprogram. But Var.all doesn't statically denote anything, and thus the
Access attribute is illegal. Since we always want conversions and .all'Access
to work the same, the conversion also should be illegal.
Since the existing ACATS test means that all existing implementations already
forbid the conversions, it seems harmless to do so.
!corrigendum E.2.2(11)
@drepl
@xbullet
@dby
@xbullet
!ACATS Test
ACATS C-Test(s) should be created to insure that no exception is raised by
operations that are excluded from the bounded error.
!appendix
From: Thomas Quinot
Sent: Thursday, March 17, 2005 7:53 AM
From the point of view of the Annex E implementor, it makes sense to
consider local and remote access-to-subprogram types as completely
different beasts. There are good reasons for RAS types to have a
representation that differs from that of local access to subprogram
types, and for the set of subprograms that they can designate to be
limited by construction to remote subprograms only.
E.2.2(11) does indeed forbid the conversion of a value of a RAS type to
a local access-to-subprogram type.
On the other hand, it looks like no clause is there in the current form
of annex E to prevent the opposite conversion (of a value of a local
access-to-subprogram type to a RAS type), altough BXE2011 checks that
such conversions are actually treated as illegal:
Remote_Proc_Ptr_0b :=
BXE2011_RCI.NoParmPtr (Local_Proc_Ptr_0); -- ERROR:
-- cannot convert local pointer to remote pointer
Remote_Proc_Ptr_0a :=
BXE2011_RT.NoParmPtr (Local_Proc_Ptr_0); -- ERROR:
-- cannot convert local pointer to remote pointer
So, I suggest that the following item be inserted in the list following
E.2.2(10) (restrictions that apply to the use of remote
access-to-subprogram types):
"for a conversion to a remote access-to-subprogram type, the converted
expression shall be of another (subtype-conformant) remote
access-to-subprogram type".
****************************************************************
From: Nick Roberts
Sent: Saturday, March 19, 2005 3:51 PM
If RAS types cannot be converted to and from LAS types, this could cause
significant difficulties for someone trying to change a package to become
(or cease to be) a remote call interface or remote types package.
I suggest, therefore, that conversion in both directions be permitted. For
the conversion from an RAS type to an LAS type, the partition implicit in
the RAS value must be the same as the partition of the LAS type (the
partition which encloses its scope). Failure should raise an exception
(perhaps Program_Error).
Making some assumptions about a likely implementation, I think conversion in
both directions can be praticably achieved by lookup table. When converting
from RAS to LAS, first the partition of the RAS value is checked to be the
same as the partition of the LAS type, then a table is used to translate
from the address of the stub subprogram to the address of the actual
subprogram. When converting from LAS to RAS, a table is used to translate
from the address of the actual subprogram to the address of the stub
subprogram, and the partition of the LAS type is used to provide the
partition for the RAS value.
As a side-note, I think it would be desirable for implementations to bypass
calling the stub subprogram when a call is made to a primitive operation of
a tagged type through a remote access-to-class-wide (RACW) value, when the
partition in which the call is made is the same as the partition of the
object designated by the RACW value. This could be achieved by a test (and,
if necessary, conversion) of the RACW value whenever it is unmarshalled.
****************************************************************
From: Thomas Quinot
Sent: Monday, March 21, 2005 9:45 AM
The conversion of RAS types to local access-to-subprogram types is
already forbidden in Ada 95, so this is not an issue.
****************************************************************
From: Nick Roberts
Sent: Tuesday, March 22, 2005 5:19 PM
I suspect this is actually a significant problem with Ada 95. I say this,
because it appears to break the generic contract model, or to make
implementations extremely difficult.
Consider the generic package:
generic
type T1 is access procedure (Foo: in Integer);
type T2 is access procedure (Foo: in Integer);
procedure Bar;
which, in its body, has:
P1: T1 := ...;
P2: T2 := T2(P1);
Nothing seems to forbid me instantiating Bar with a remote
access-to-subprogram (RAS) type as the actual for T1, and a local
access-to-subprogram (LAS) type as the actual for T2. In this case, a
conversion from a RAS type to a LAS type seems to be required.
Is an implementation supposed to detect when I've done this, and reject it
(the instantiation, I suppose)? It would seem easier just to have the
conversions defined.
A similar problem seems to apply to remote access-to-class-wide types.
Perhaps clauses need to be added to E.2.2 (in addition to what Thomas
suggested) to forbid the use of remote access-to-subprogram/class-wide types
as actuals in a generic instantiation. But I'm not happy with this solution,
since I feel it would tend to restrict the usefulness of remote access types
too severely.
I feel forbidding conversions between RAS/CW and LAS/CW types goes against
the spirit of the language, and isn't technically necessary. I would prefer
that the restrictions were removed altogether; this couldn't break existing
correct Ada 95 code (since it only permits something that was previously
forbidden). (I suspect compiler maintainers will gripe about it :-)
****************************************************************
From: Thomas Quinot
Sent: Wednesday, March 23, 2005 4:49 AM
> I feel forbidding conversions between RAS/CW and LAS/CW types goes against
> the spirit of the language, and isn't technically necessary.
Nothing is ever technically necessary. Forbidding conversions between
local and remote access-to-subprogram types is worthwhile because
allowing them would impose a completely unreasonable burden on the
runtime library (forcing any partition that has visibility upon a remote
access-to-subprogram type to embed server-side code and server stubs for
any subtype-conformant local subprogram).
The case of RACWs is completely different, please do not mix issues.
> that the restrictions were removed altogether; this couldn't break existing
> correct Ada 95 code (since it only permits something that was previously
> forbidden).
Forbidding conversions of local access-to-subprogram types to remote
ones as suggested won't in fact change the behaviour of conforming
compilers either, since they already have to forbid them in order to
pass BXE2011.
****************************************************************