Is setjmp/longjmp ok?

Discussion in 'C Programming' started by Michael B Allen, May 1, 2004.

  1. Should setjmp/longjmp really be used in a fast mundane ANSI C piece of
    code? Or is it frowned apon like goto? I have a need but I don't want to
    use something that is costly, isn't supported consistenly, or something
    that might pull in exotic text segments, etc.

    Specifically I have a hairly algorithm loop that uses what is currently
    a macro V. Here's a snipplet:

    for (k = d; k >= -d; k -= 2) {
    if (k == -d || (k != d && V(fwd, m, k - 1) < V(fwd, m, k + 1))) {
    x = V(fwd, m, k + 1);
    } else {
    x = V(fwd, m, k - 1) + 1;
    }
    y = x - k;

    But now I must replace the V macro with a function (say vfn) that will
    need to indicate an error has occured. The question is do I;

    A) replace each macro V with a function that returns -1 to indicate an
    error has occured and check it with each call like:

    for (k = d; k >= -d; k -= 2) {
    int v1 = vfn(fwd, m, k - 1);
    int v2 = vfn(fwd, m, k + 1);
    if (v1 == -1 || v2 == -1) {
    return -1;
    }
    if (k == -d || (k != d && v1 < v2)) {
    if ((x = vfn(fwd, m, k + 1)) == -1) {
    return -1;
    }
    ... yuk - and vfn is called regardless of
    whether or not k == -d or k == d

    or

    B) use longjmp when the error occurs to cleanly return regardless of
    the state of the hairy loop like:

    if (setjmp(env) == 1) {
    return -1;
    }
    for (k = d; k >= -d; k -= 2) {
    if (k == -d || (k != d && vfn(fwd, m, k - 1, &env) < vfn(fwd, m, k + 1, &env))) {
    x = vfn(fwd, m, k + 1, &env);
    } else {
    ...

    where vfn calls longjmp when the error occurs like:

    longjmp(*env, 1);

    Thanks,
    Mike
    Michael B Allen, May 1, 2004
    #1
    1. Advertising

  2. Michael B Allen

    -wombat- Guest

    Michael B Allen wrote:

    > Should setjmp/longjmp really be used in a fast mundane ANSI C piece of
    > code? Or is it frowned apon like goto? I have a need but I don't want to
    > use something that is costly, isn't supported consistenly, or something
    > that might pull in exotic text segments, etc.


    setjmp/longjmp tends to be supported across a lot of platforms, so I
    wouldn't worry about its unavailability.

    The most frequent usage is in signal handlers, e.g., signal(SIGINT,
    your_function_here), to return back to main() or an event loop.

    While your usage isn't particularly evil, why would you want to complicate
    your code with non-local gotos if you can unwind the stack cleanly? longjmp
    may return you back a little faster, but YMMV.
    -wombat-, May 1, 2004
    #2
    1. Advertising

  3. Michael B Allen

    Jack Klein Guest

    On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <>
    wrote in comp.lang.c:

    > Michael B Allen wrote:
    >
    > > Should setjmp/longjmp really be used in a fast mundane ANSI C piece of
    > > code? Or is it frowned apon like goto? I have a need but I don't want to
    > > use something that is costly, isn't supported consistenly, or something
    > > that might pull in exotic text segments, etc.

    >
    > setjmp/longjmp tends to be supported across a lot of platforms, so I
    > wouldn't worry about its unavailability.


    All implementations of C for hosted environments support setjmp and
    longjmp. Anything that does not, in a hosted environment, is not a C
    implementation regardless of claims to the contrary.

    > The most frequent usage is in signal handlers, e.g., signal(SIGINT,
    > your_function_here), to return back to main() or an event loop.


    Calling longjmp in a signal handler that was invoked asynchronously,
    that is other than by a call to raise() or abort(), produces undefined
    behavior.

    > While your usage isn't particularly evil, why would you want to complicate
    > your code with non-local gotos if you can unwind the stack cleanly? longjmp
    > may return you back a little faster, but YMMV.


    Generally speaking, the need to use longjmp in an ordinary program for
    ordinary error handling indicates a need for a better design. They
    are exceptions, of course, but they are very, very few.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, May 1, 2004
    #3
  4. Michael B Allen

    -wombat- Guest

    Jack Klein wrote:

    > On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <>
    > wrote in comp.lang.c:
    >
    >> The most frequent usage is in signal handlers, e.g., signal(SIGINT,
    >> your_function_here), to return back to main() or an event loop.

    >
    > Calling longjmp in a signal handler that was invoked asynchronously,
    > that is other than by a call to raise() or abort(), produces undefined
    > behavior.


    Many years ago, when only the K&R manual existed as a mere hint of a spec
    and AT&T 3b2s were current hardware, that's what I was using setjmp and
    longjmp for -- mostly in daemon processes when something got into trouble
    and we wanted to hit the daemon with a signal to get it to jump back to its
    read() loop. So we used longjmp to return more than one level in the stack
    back.

    "undefined behavior" is a little strong (it's spec-speak for "Programmer!
    CYA!") "unpredictable" is more apropos because the programmer now has to be
    careful that whatever the longjmp returns to has some kind of sane state or
    at least some state that can be salvaged. The onus is on the coder to DTRT.
    Besides, the signal handler's stack frame should be deeper than the
    original setjmp's caller's (hopefully), so there's really no major problem
    even if the handler is called async. Of course, there are a lot of ways to
    get this wrong.

    Other creative uses I've seen of setjmp/longjmp is in Scheme-to-C call/cc
    support as well as primitive, non-preemptive user-level thread packages
    (yield() is just a call to setjmp to save current thread state and longjmp
    back to the thread scheduler.) In the latter case, most OSs have some kind
    of thread support so there's no longer a real need for that hack.
    -wombat-, May 2, 2004
    #4
  5. On Sat, 01 May 2004 16:34:47 -0400, Jack Klein wrote:
    >> While your usage isn't particularly evil, why would you want to
    >> complicate your code with non-local gotos if you can unwind the stack
    >> cleanly? longjmp may return you back a little faster, but YMMV.

    >
    > Generally speaking, the need to use longjmp in an ordinary program for
    > ordinary error handling indicates a need for a better design. They are
    > exceptions, of course, but they are very, very few.


    You said "exceptions" and that is precisely what the example given needs
    -- an exception handler. The purpose of an exception handler is to provide
    error handling without disrupting the normal flow of the primary code
    path. Considering C does not have exceptions setjmp/longjmp is the next
    closest thing.

    But then I suppose my question has been answered -- using setjmp/longjmp
    in this context is perceived as complicated or poor design.

    Mike
    Michael B Allen, May 2, 2004
    #5
  6. Michael B Allen

    Richard Bos Guest

    -wombat- <> wrote:

    > Jack Klein wrote:
    >
    > > On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <>
    > > wrote in comp.lang.c:
    > >
    > >> The most frequent usage is in signal handlers, e.g., signal(SIGINT,
    > >> your_function_here), to return back to main() or an event loop.

    > >
    > > Calling longjmp in a signal handler that was invoked asynchronously,
    > > that is other than by a call to raise() or abort(), produces undefined
    > > behavior.

    >
    > Many years ago, when only the K&R manual existed as a mere hint of a spec
    > and AT&T 3b2s were current hardware, that's what I was using setjmp and
    > longjmp for


    And in those years, such functions behaved differently - often not at
    all, or very system-dependently. Today, we have harnessed the power of
    fire, and we have the Standard.

    > "undefined behavior" is a little strong (it's spec-speak for "Programmer!
    > CYA!")


    Undefined behaviour is _exactly_ right:

    # [#5] If the signal occurs other than as the result of
    # calling the abort or raise function, the behavior is
    # undefined if ...
    # ... or the signal
    # handler calls any function in the standard library other
    # than the abort function or the signal function with the
    # first argument equal to the signal number corresponding to
    # the signal that caused the invocation of the handler.

    That's from n869, btw. I believe the actual Standard says the same.

    > "unpredictable" is more apropos because the programmer now has to be
    > careful that whatever the longjmp returns to


    Once you call longjmp() from a signal handler, it is not even guaranteed
    _that_ you return anywhere, let alone that it is stable.

    Richard
    Richard Bos, May 3, 2004
    #6
  7. In article <>, Michael B Allen <> writes:
    >
    > But then I suppose my question has been answered -- using setjmp/longjmp
    > in this context is perceived as complicated or poor design.


    Certainly it is by some, but the same can be said of essentially any
    C construct. You can get good style advice from comp.lang.c, but
    when you're considering alternatives that are equally valid per the
    standard, remember that style recommendations are subjective. There
    may be good arguments to be made in their favor, but not on the same
    order as "this produces undefined behavior" or the like.

    In this particular case, for example, setjmp / longjmp wouldn't
    bother me, if I saw them in code I was maintaining. Their use would
    be confined to a small segment of code and the application is clear.
    I would prefer to see the jmp_buf passed as a parameter to the
    function calling longjmp, though.

    --
    Michael Wojcik

    Although he was an outsider, and excluded from their rites, they were
    always particularly charming to him at this time; he and his household
    received small courtesies and presents, just because he was outside.
    -- E M Forster
    Michael Wojcik, May 3, 2004
    #7
  8. Michael B Allen

    -wombat- Guest

    Richard Bos wrote:
    >> "undefined behavior" is a little strong (it's spec-speak for "Programmer!
    >> CYA!")

    >
    > Undefined behaviour is _exactly_ right:
    >
    > # [#5] If the signal occurs other than as the result of
    > # calling the abort or raise function, the behavior is
    > # undefined if ...
    > # ... or the signal
    > # handler calls any function in the standard library other
    > # than the abort function or the signal function with the
    > # first argument equal to the signal number corresponding to
    > # the signal that caused the invocation of the handler.
    >
    > That's from n869, btw. I believe the actual Standard says the same.


    It's saying that the standard library makes no gaurantees if anything other
    than raise() or abort() are called. That's not to say that things don't
    work -- plenty of software out there actually does call standard library
    functions from inside signal handlers, SIGINT being the prime example.

    >> "unpredictable" is more apropos because the programmer now has to be
    >> careful that whatever the longjmp returns to

    >
    > Once you call longjmp() from a signal handler, it is not even guaranteed
    > _that_ you return anywhere, let alone that it is stable.


    Your scenario only makes sense if the signal handler is called with a
    separate stack, but even then that tends to fly in the face of reality.
    jmp_buf saves a lot of machine state, including the stack pointer. Since
    setjmp is generally called in an upper stack frame vs. longjmp being called
    in a lower stack frame, it's not completely unstable and the return point
    isn't totally undefined. The only place/time that can happen is if the
    programmer violates the up/down ordering of stack frames, which would
    indicate that the programmer doesn't understand how to use setjmp or
    longjmp properly.

    Besides, if what you said is true, a lot of software would cease to work.
    Can the programmer do some bad things to the software by using
    setjmp/longjmp? Yes. Does it take a lot of extra thinking to work with
    setjmp/longjmp? Yes.
    -wombat-, May 3, 2004
    #8
  9. Michael B Allen

    Alan Balmer Guest

    On Sun, 02 May 2004 00:00:04 -0400, Michael B Allen
    <> wrote:

    >On Sat, 01 May 2004 16:34:47 -0400, Jack Klein wrote:
    >>> While your usage isn't particularly evil, why would you want to
    >>> complicate your code with non-local gotos if you can unwind the stack
    >>> cleanly? longjmp may return you back a little faster, but YMMV.

    >>
    >> Generally speaking, the need to use longjmp in an ordinary program for
    >> ordinary error handling indicates a need for a better design. They are
    >> exceptions, of course, but they are very, very few.

    >
    >You said "exceptions" and that is precisely what the example given needs
    >-- an exception handler. The purpose of an exception handler is to provide
    >error handling without disrupting the normal flow of the primary code
    >path. Considering C does not have exceptions setjmp/longjmp is the next
    >closest thing.
    >
    >But then I suppose my question has been answered -- using setjmp/longjmp
    >in this context is perceived as complicated or poor design.
    >

    Not always. It's like goto, it may be a sign of poor design, but there
    are places where it's appropriate.

    Having said that, I must admit that I've almost never had a situation
    where it was appropriate, and when I've seen setjmp/longjmp while
    maintaining old code, there has almost always been a better way.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, May 3, 2004
    #9
  10. Michael B Allen

    CBFalconer Guest

    Alan Balmer wrote:
    > Michael B Allen <> wrote:
    >

    .... snip ...
    >>
    >> But then I suppose my question has been answered -- using
    >> setjmp/longjmp in this context is perceived as complicated or
    >> poor design.

    >
    > Not always. It's like goto, it may be a sign of poor design, but
    > there are places where it's appropriate.
    >
    > Having said that, I must admit that I've almost never had a
    > situation where it was appropriate, and when I've seen
    > setjmp/longjmp while maintaining old code, there has almost
    > always been a better way.


    To all practical purposes the presence of exit() and atexit()
    obviate most needs for setjmp/longjmp. The glaring exception
    would be when you don't want to let the user access the underlying
    machine in any circumstances, and even then you probably want
    passworded code to exit the process for maintenance purposes.

    --
    "I'm a war president. I make decisions here in the Oval Office
    in foreign policy matters with war on my mind." - Bush.
    "Churchill and Bush can both be considered wartime leaders, just
    as Secretariat and Mr Ed were both horses." - James Rhodes.
    CBFalconer, May 4, 2004
    #10
  11. Michael B Allen

    Richard Bos Guest

    -wombat- <> wrote:

    > Richard Bos wrote:
    > >> "undefined behavior" is a little strong (it's spec-speak for "Programmer!
    > >> CYA!")

    > >
    > > Undefined behaviour is _exactly_ right:
    > >
    > > # [#5] If the signal occurs other than as the result of
    > > # calling the abort or raise function, the behavior is
    > > # undefined if ...
    > > # ... or the signal
    > > # handler calls any function in the standard library other
    > > # than the abort function or the signal function with the
    > > # first argument equal to the signal number corresponding to
    > > # the signal that caused the invocation of the handler.
    > >
    > > That's from n869, btw. I believe the actual Standard says the same.

    >
    > It's saying that the standard library makes no gaurantees if anything other
    > than raise() or abort() are called.


    Exactly. And this is called undefined behaviour in the Standard.

    > That's not to say that things don't
    > work -- plenty of software out there actually does call standard library
    > functions from inside signal handlers, SIGINT being the prime example.


    Sure, but those programs assume C _and_ something else, often POSIX.
    What POSIX defines in addition, or possibly even contradiction, to the
    ISO C Standard is off-topic here, since this is a newsgroup about C, not
    about C-for-some-popular-OSes-only.

    > >> "unpredictable" is more apropos because the programmer now has to be
    > >> careful that whatever the longjmp returns to

    > >
    > > Once you call longjmp() from a signal handler, it is not even guaranteed
    > > _that_ you return anywhere, let alone that it is stable.

    >
    > Your scenario only makes sense if the signal handler is called with a
    > separate stack,


    No - my scenario is explicitly allowed by the Standard. Who knows - it
    might be a safety feature of the OS. My point is that _unless_ you
    assume additional, off-topic, standards you cannot assume that calling
    longjmp() from a signal handler does anything at all.

    > Besides, if what you said is true, a lot of software would cease to work.


    Nonsense. What I say is true, and a lot of software is not written
    entirely in ISO C.

    Richard
    Richard Bos, May 4, 2004
    #11
  12. Michael B Allen

    -wombat- Guest

    Richard Bos wrote:
    >> >> "unpredictable" is more apropos because the programmer now has to be
    >> >> careful that whatever the longjmp returns to
    >> >
    >> > Once you call longjmp() from a signal handler, it is not even
    >> > guaranteed _that_ you return anywhere, let alone that it is stable.

    >>
    >> Your scenario only makes sense if the signal handler is called with a
    >> separate stack,

    >
    > No - my scenario is explicitly allowed by the Standard. Who knows - it
    > might be a safety feature of the OS. My point is that _unless_ you
    > assume additional, off-topic, standards you cannot assume that calling
    > longjmp() from a signal handler does anything at all.
    >
    >> Besides, if what you said is true, a lot of software would cease to work.

    >
    > Nonsense. What I say is true, and a lot of software is not written
    > entirely in ISO C.


    The language has to assume a machine model, without which the language is
    utterly useless. The language maps to that hypothetical, perfect virtual
    machine. setjmp/longjmp make certain assumptions based on the VM's
    structure such that it has validity and will work. One of those VM features
    is a stack-based architecture, without which, a lot of C features would be
    hard to implement (not impossible, but much harder.)

    What you've incorrectly asserted is that "What the standard says must
    arbitrarily be true." The standard gives the RTL implementor leeway in the
    RTL's implementation such that no gauruntees have to be made in special
    situations. No more and no less. Thus, if something doesn't work, the RTL
    implementor can point to the standard and assert that they implemented the
    standard correctly.

    Nothing I said had to do with special OS support structures. I merely
    pointed out some of the more common uses of setjmp/longjmp. Moreover, I
    pointed how reality (and the VM that maps to the C language) tends to fly
    in the face of what the ISO standard would call "undefined" behavior.

    But, hey, must be nice to live inside the ISO standard cocoon. Meanwhile,
    there's reality for the rest of us.
    -wombat-, May 4, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Baruchel

    How dirty is setjmp+fopen+longjmp ?

    Thomas Baruchel, Oct 2, 2003, in forum: C Programming
    Replies:
    2
    Views:
    448
    Eric Sosman
    Oct 2, 2003
  2. Mantorok Redgormor

    setjmp, longjmp

    Mantorok Redgormor, Nov 12, 2003, in forum: C Programming
    Replies:
    2
    Views:
    418
    Ian Woods
    Nov 12, 2003
  3. someone
    Replies:
    5
    Views:
    3,437
    SM Ryan
    May 1, 2004
  4. Ravi Uday

    setjmp/longjmp

    Ravi Uday, Aug 3, 2004, in forum: C Programming
    Replies:
    2
    Views:
    536
    Dave Vandervies
    Aug 6, 2004
  5. Jrferguson

    A bit off topic; setjmp/longjmp

    Jrferguson, Oct 29, 2004, in forum: C Programming
    Replies:
    4
    Views:
    482
    Dan Pop
    Nov 2, 2004
Loading...

Share This Page