setjmp/lonjmp (was: vinum warning)

[Greg 'groggy' Lehey]

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.

Agreed.

> 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.

Greg
--
Finger grog at xxxxxxxxx for PGP public key.
See complete headers for address and phone numbers.
Attachment:
pgp00004.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20050203/0cf83654/attachment-0020.obj>