At 04:31 PM 3/23/01 -0800, you wrote:
>This has nothing to do with fastpathing and object code optimization. C
>doesn't have exception handling, so you either have to remember to undo
>allocations etc. in failure cases all through the code, or you stick your
>undo code at the end of the function and have all failure cases jump to the
>relevant label. It's not pretty, but it's much less error-prone e.g.
Really? I have a "cleanup" function that can be called during failure
cases (and success cases -- but you didn't mention that) so that the cost
is very low and I don't have to code ANY labels.
But then again, I'm a double-pipe abuser, in that I tend to code "atomic"
sequences as
if ((a) || (b) || (c) || (d) || (e) || (f) || (g) || ... ) { something
failed} else {it all worked!}
and make sure that the failure value is non-zero for each a, b, c, d, and
so forth.
I remember looking at the generated code from one compiler for x86 and
seeing a series of short jumps to short jumps to short jumps... to the
failure case, which in that particular sequence saved about 100 bytes. I
haven't looked at GCC output yet to see what it does, but working in a
32-bit system instead of a 16-bit system I tend to care a little less about
"efficiency".
Does that mean that I avoid "goto"? No. Like every other construct in the
C language, there is a valid and appropriate use for every single
thing. The key is recognizing when the goto is appropriate.
Another thing you will see in my code is resource pointers being
initialized to zero on entry, set to non-zero values as resources are
allocated, and then conditionally released based on whether the value is
zero or non-zero. It makes recovery from malloc failures easier, for one
thing.
Satch. the || Abuser.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:22 EST