| 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. 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@xxxxxxxxx for PGP public key. See complete headers for address and phone numbers.
Attachment:
pgp00004.pgp
Description: PGP signature