DragonFly BSD
DragonFly kernel List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: setjmp/lonjmp (was: vinum warning)

From: "Greg 'groggy' Lehey" <grog@xxxxxxxxx>
Date: Fri, 4 Feb 2005 10:30:47 +1030

On Friday,  4 February 2005 at  0:40:05 +0100, Joerg Sonnenberger wrote:
> On Fri, Feb 04, 2005 at 09:35:16AM +1030, Greg 'groggy' Lehey wrote:
>>> They destroy the normal flow of code.
>> For your definition of "normal".
> Well, I very much like calling graphs which are shaped like trees.
> Such a tree makes it very easy to follow the code.


> Recursion needs special care and has to be checked. Passing error
> codes up the same path the code took down makes it easy to verify
> what errors can come from where. This is what I consider
> "normal". C++-style exceptions can simplify code,

You'll notice that they're implemented with setjmp()/longjmp().

> but remove this explicit control flow, which might be a good idea
> for large scale userland applications, but IMO is not good for the
> kernel.

That depends on the function.  In general, the same considerations
apply.  Do you use exit() in userland?  That's effectively a longjmp()
back to main() followed by a return.  I don't know anybody who
actually *always* returns to main() from any large program.

>>> Even worse, they allow jumping out of the current flow to a
>>> different stack.
>> There are plenty of constructs that can be abused.  Vinum doesn't do
>> this.
> Well, I would call vinum_scandisk calling setjmp and afterwards
> calling parse_config, which can itself call vinum_scandisk, at least
> dangerous.

On the contrary, that's the advantage.  Under these circumstances
you're building a large number of stack frames, and none of the
intervening ones interest you.

Finger grog@xxxxxxxxx for PGP public key.
See complete headers for address and phone numbers.

Attachment: pgp00004.pgp
Description: PGP signature

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]