Version 1.2 of ais/ai-00215.txt

Unformatted version of ais/ai-00215.txt version 1.2
Other versions for file 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
!priority Medium
!difficulty Easy
!subject Returning remote class-wide values.
!summary
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 E.4(18).
!question
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.]
!recommendation
(See summary.)
!wording
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.
!discussion
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.
!appendix

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
problem.

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


Questions? Ask the ACAA Technical Agent