[coyotos-dev] CapIDL array error?

[Jonathan S. Shapiro]

Okay. I think this is fixed now, but let me explain what is going on
here, because it is a bit puzzling.

The C semantics for arrays is "pass by reference". The CapIDL semantics
for arrays is "pass by value". This raises a design issue: how should
CapIDL emit type definitions for these types?

CapIDL currently emits a typedef of the form:

  typedef baseType  typeName[size];

This has call-by-reference semantics. On the server side, CapIDL emits
an explicit copy of the value in order to avoid a collision between the
incoming arguments and the outgoing arguments (which are stored in a
union, and therefore have overlapping storage). I am considering
removing the union on the server side, in which case the extra copy
could be eliminated (there are other reasons to want to eliminate this
copy in any case).

The other option is for CapIDl to emit something like:

  typedef struct {
    baseType elem[size];
  } typeName;

which has the effect of ensuring that the type is *always*
call-by-value. CapIDL semantics is preserved wherever the type is used.

If the array appears inside a struct, then it is already by-value, and
there is no real difference here. If the array appears as a procedure
argument, the effect is to force a copy at the argument boundary. For
*outgoing* arrays, the argument is necessarily by-reference in any case.
So the issue here really concerns procedure arguments, and only
*incoming* procedure arguments.

My intuition here is that most of the cases of incoming arrays are
read-only, and that CapIDL should pass array arguments by reference on
the server side (that is: it should do what it does now).

However, I also believe that the current "extra copy" is unnecessary,
and should be removed by replacing the current in/out union on the
server side with a pair consisting of (in param space, out param space).
Once that is done, the array can be passed by reference without further
copies.


Reactions?


shap