!standard E.4 (18) 99-02-12 AI95-00215/01 !class binding interpretation 99-02-12 !status work item 99-02-12 !priority Medium !difficulty Easy !subject Returning remote class-wide values. !summary 99-02-12 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 99-02-12 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 99-02-12 (See summary.) !wording 99-02-12 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 99-02-12 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 99-02-12 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. *************************************************************