Version 1.2 of ais/ai-00215.txt
!standard E.4 (18) 99-02-12 AI95-00215/01
!class binding interpretation 99-02-12
!status ARG Approved 9-0-0 99-03-24
!status work item 99-02-12
!subject Returning remote class-wide values.
A check is made on the result of a remote function call that returns a
class-wide type that it does not violate the conditions described in section
The rule of E.4(18) requires a check for the actual parameter of a remote
subprogram call with a formal parameter of a class-wide type. This check
is to prevent the passage of objects whose type is not a "communicable" type.
However, no check is required for a function returning a class-wide object.
Therefore, a function can return an object that is not of a "communicable"
type. Was this intended? [No.]
Add the following text to E.4(18):
In a remote function call which returns a class-wide type, the same check is
made on the function result.
The purpose of the rule E.4(18) is to prevent the passage of objects which
have types that are not "communicable" types. (That is, types which are not
known to the other partitions.) Normally this is enforced at compile-time,
but with class-wide types, the check needs to be a run-time check.
The rule would not be helpful if there was a way to pass objects of types
that are not "communicable". However, exactly that can be done by returning
such an object from a function. Clearly, a check needs to be made on such
results as well.
Note that the return statement in the function itself cannot know whether
or not it was called remotely. Therefore, the check must be made by the
remote function call return code when the object is marshalled to be
returned to the caller.
Randy Brukardt, 2-12-99
This AI comes from a discussion of the repaired ACATS test CXE4005.
The repaired version uses a remote-classwide function to get an illegal
value to pass for the E.4(18) check. (Return_Open_Tagged_Type_Class). This
routine is included in a Remote_Call_Interface package.
It seems curious that the rule of E.4(18) does not apply to a function result.
Note that the effect of returning an object that would violate E.4(18) from a
function is essentially the same as that of passing a parameter that violates
E.4(18). Either allows values with tags of types not visible to a partition
to be passed to a partition.
I note that there is a a possible problem with the formulation of the AI.
That is that the caller makes the check for a parameter of a remote subprogram
call. That is not a problem, as the caller always knows that it is making
a remote subprogram call. However, for a function result, the callee must
make the check. But the callee does not necessarily know that it was called
remotely. (The caller cannot make the check, as the bad item will already
have had to be passed.) I have left the rule as it originally was, assuming
that the marshalling code for the function result will actually make the
check. The ARG should consider whether this would be an implementation
Questions? Ask the ACAA Technical Agent