setjmp/lonjmp (was: vinum warning)

Matthew Dillon dillon at apollo.backplane.com
Thu Feb 3 16:26:31 PST 2005


:>      I'm going to nit on this.
:>=20
:>      Using longjmp is evil.  Period.
:
:Is that the only justification you have for your opinion?
:
:Greg

    The problem, Greg, is that when you use something like that in
    a large project you basically remove a large number of programmers
    from the set of programmers able to work, maintain, and extend your code.

    Your code is especially difficult to maintain.  I'm not saying its bad,
    just that it's especially difficult for people other then yourself to
    wrap their hands around and actually work with because of the lack of
    in-code documentation, weird code constructions that nobody else uses,
    weird indentation that doesn't seem to work with anyone else's editor,
    the extremely deeply nested statements you have, lack of 
    compartmentalization of major function sets, and other things.  I've
    tried to do cleanups of your vinum code before and, believe me, it is a
    frustrating experience!

    Now, so you don't feel bad, Kirk's code comes in a close second.  
    Excellent code, but extremely difficult for someone other then kirk to
    maintain.  In Kirk's case the main problem is a lack of in-code
    documentation of the very complex algorithms he uses in softupdates
    coupled with his propensity to hack up other parts of the system to
    crowbar pieces in (like the background bitmap writing code, the snapshot
    code, the major reliance on the precise actual implementation of other
    pieces of VFS system in order to be able to assume certain side effects
    which are also not documented anywhere in the code, and so forth).

    It's probably a generational thing.  One of the reasons why I am allowing
    people to do major cleanups of our code base is precisely to try to make
    the code more maintainable and more comfortable for more recent
    generations of programmers.

						-Matt






More information about the Kernel mailing list