Alexander Viro wrote:
>
> On Sun, 8 Oct 2000, Daniel Phillips wrote:
>
> > Linus Torvalds wrote:
> > > This, btw, is why Linux returns error numbers as -Exxx instead of using
> > > "-1" and "errno" - I dislike the latter enormously.
> >
> > It's not just a matter of disliking it, it's also not reentrant.
>
> ??? Yes it is, if pointer goes to an auto variable in caller. I also do
> not like it, but reentrancy is _not_ the reason.
1 /*
2 * linux/lib/errno.c
3 *
4 * Copyright (C) 1991, 1992 Linus Torvalds
5 */
6
7 int errno;
8
Doesn't look very automatic to me.
> > It would be nice if we could return a struct consisting of the error and
> > result. I'm not sure if this is allowed in C now or not. It didn't
> > work when I tried it with gcc: it seems to consider a struct-valued
> > function to be a void-valued. Odd.
>
> Eww... _Please_, let's not mess with structures in arguments/return
> values/assignments. For one thing, it's bloody inefficient on many
> platforms. For another, I don't like the idea of kernel becoming a
> crash-dummy for gcc folks.
It doesn't have to be inefficient - on x86 for example it's common to
return double results in ax:dx. Then a two-int struct can be passed
back just like a double.
If it was solid on all platforms I'd use it (it isn't - flunked my test
case, bad start). Even if it wasn't particularly efficient, so long as
not grossly inefficient (passing back a linked list of bits would be too
slow). Where correctness matter more than efficiency, which is most
places, why not?
The other problem is that C doesn't have any nice syntax for handling a
struct result. You have to do something like:
struct result result = unreliable();
if (result.errror) goto do_something;
<do something with result.value>
which isn't a lot better than:
int err;
int value = unreliable(&err);
if (err) goto do_something;
<do something with value>
To be nice to use, it would have to look something like:
with unreliable() if (!error) <do something with value>
which is essentially a lambda expression. But that's another language.
Throwing and catching exceptions lets you get rid of a huge amount of
this ugly, error prone kind of code, but there is a well known problem:
C doesn't have exceptions. So that's out. I think the answer is, there
is no answer. One day I'd like to take some time and hack in an
exception thrower/catcher as a demonstration.
> Functions returning structures are in a very dark area of C - let somebody
> else break their necks debugging the compilers.
That makes sense to me :-)
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
