Re: 2.4.0-test9: minixfs causing oopsen when out of inodes

From: Daniel Phillips (news-innominate.list.linux.kernel@innominate.de)
Date: Sun Oct 08 2000 - 17:13:54 EDT

  • Next message: Martin Diehl: "Re: poll(2) semantics changed in 2.4.0-? vs. 2.2.16?"

    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 majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/
    



    This archive was generated by hypermail 2b29 : Sun Oct 08 2000 - 17:18:35 EDT