[coyotos-dev] [CapROS-devel] CapIDL design issue -- return codes

[Jonathan S. Shapiro]

Okay, I want to try to summarize where I am with all of this, because I
need to have this done this weekend. Here is where I am on the subject
of client stubs. I'm not even going to think about IDL source
compatibility issues at this time.

1. Because stubs are inlined, there is no requirement (other than
   convenience) that any two clients (or even a library and its caller)
   agree about how their client-side stubs are generated.

2. It is fairly straightforward for the client stub generator to go
   either way.

3. Error handling is simpler and more consistently handled if client
   stubs return the result code rather than the result type.

4. The capability return value issue is very straightforward if
   result codes are returned. When the return type is rotated to the
   end it is given an argument position. As a side effect, it becomes
   straightforward to say where the return capability should go.

   In fact, the main reason that I had never noticed the problem was
   that the existing CapIDL implementation had always done this
   rotation.

5. Note that for C++ client stubs the issue of uninitialized structures
   does not really apply, because IDL exceptions convert to C++
   exceptions, with the context that the failed initializing context
   is abandoned.

   This generalizes to any language having exceptions. It is very
   regrettable (in my mind) that the C0X standards effort is not
   considering exception handling. Yet another reason to abandon
   C for good.

So I currently think that the real issue here is: what should the
default be? My conclusions on this will follow shortly.


shap