Re: IDL issue

[Neal H. Walfield]

At Sun, 08 Jul 2007 00:03:10 -0400,
Jonathan S. Shapiro wrote:
>   1. It leads to more consistent error checking:
> 
>        CHECKRESULT(f(arg, &retVal, &idlEnv));
>        // where CHECKRESULT is a macro that may cause exceptional
>        // control flow, and any code below this point can assume
>        // the operation succeeded.
> 
>   2. It avoids an initialization problem. Consider the "return result
>      type" idiom when an exceptional code is returned:
> 
>        float retVal = f(arg, &idlEnv);
>        CHECKRESULT(idlEnv);

I have a preference for the former, however, that may just be
familiarity with the construct.


> For all of these reasons (and some others), Microsoft's DCOM design has
> all interface methods returning an HRESULT, which is basically the error
> code. This may be a matter of convention.

This is similar to the direction POSIX interface has taken in recent
years.  New functions tend to return error codes and not overload
return values.  For instance, ftell, an old function, returns the
position of the passed steam.  If the position is -1, then a failure
occurred.  pthread_create, on the other hand, returns an error code
and the object in an argument.  This approach also has the advantage
that it simplifies code when pthread_t is a struct.

> I am honestly not sure what to do here, and I would appreciate input.
> The bottom line, I think, is that *any* failure to check results is
> potentially fatal in this type of code no matter which way the IDL is
> generated. Either idiom can be maintained by a careful programmer.

An interesting counterexample may be that of POSIX file streams.
Instead of checking after every read or write for an error, the
programmer may just check if an error occurred at the end of a
sequence of operations using ferror.  This can greatly simplify the
code.

> The early CORBA example binding went the other way. Procedures return
> their return value, and error codes are returned via the IDL
> environment. GNOME IDL followed this example, which means that we may
> have a source-level compatibility issue to consider here.

What sort of source-level compatibility issues do you imagine here?  I
would think that GNOME will continue to use its own IDL compiler, that
it will not directly use coyotos types (e.g., capabilities), but that
it may provide a transport back-end that directly uses Coyotos IPC (as
opposed to, e.g., domain sockets).

> If we choose to adopt the "return the return value" convention, it is
> still necessary to handle capability returns specially in C, because the
> caller must say where the incoming capability is to be stored (we cannot
> get compiler help for this from an unmodified compiler).

How is this different from returning a struct?  There is a general
rule of thumb not to return large structs from function calls.
Instead, the convention is for either the function allocates memory or
the caller to pass a pointer to a block of allocated memory.

Neal