Re: setjmp/lonjmp (was: vinum warning)
--6k8oSBQUGGHRSAt9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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@lemis.com for PGP public key.
See complete headers for address and phone numbers.
--6k8oSBQUGGHRSAt9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQFCArsvIubykFB6QiMRAq9xAJ92medHoUYsAreggWWWUbjoAI+KYQCeMXSi
E+S3qR/QwBbvGtFtcMEmoKg=
=5H+B
-----END PGP SIGNATURE-----
--6k8oSBQUGGHRSAt9--
討論串 (同標題文章)
完整討論串 (本文為第 5 之 11 篇)：