Re: IDL issue

"Michal Suchanek" <[email protected]>
Newsgroups gmane.os.hurd.l4
Message-ID <[email protected]>
On 09/07/07, Jonathan S. Shapiro <[email protected]> wrote:
> On Mon, 2007-07-09 at 14:28 +0200, Espen Skoglund wrote:
> > I agree with you.  Returning the error code is more consistent...
>
> I think that this outcome is interesting. So far, we have Shapiro
> (Coyotos), Skoglund (L4), Landau (CapROS), Adams (Coyotos), Walfield
> (Hurd, L4), and everybody else I have talked to about this agreeing that
> returning the error code is the preferred outcome.
>
> Given this, it is interesting (and perhaps unfortunate) that the various
> L4 IDL compilers do not agree with us. :-)
>
> > This might eliminate some problems due to sloppy programming.  The one
> > argument I can think of in favour of returning the result value is a
> > performance related one.  The architecture calling conventions...
>
> Yes, but as Tom Bachmann pointed out, this is not an issue when stubs
> are inlined. Inlining stubs seems to be a universal assumption, though
> it is probably not an optimization to do this on most architectures.

Hello

I do not have that much experience with C programming. However, I had
to cut through the POSIX jungle of different interfaces on quite a few
occasions. And I think that a bit of consistency would make the
interface easier to learn. Probably easier to use and understand
existing code as well.

Thus I would favor returning of the error code which is well defined
for all operations.

However, I wonder why the environment argument is the last. Assuming
it is needed for all calls it would be more consistent if it were the
first argument. The last position is sort of consistent but it is not
so fixed in C.
Also making some logical rules for ordering of the other arguments
would be helpful.

Well, if I ever get to use the Coyotos interfaces I will try to use
whatever is available by then. But an interface that is easier to
understand is always welcome :-)

Thanks

Michal
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.