longjmp vs goto

[Nimmi Srivastav]

Can someone kindly clarify the distinction between long jumps and
gotos? Why is one frowned upon and not the other? Is there really
any situation where use of longjmp becomes inevitable? A real-life
code snippet would surely help.

Regards,
Nimmi

[John Bode]

ni************* @yahoo.com (Nimmi Srivastav) wrote in message news:<8b******* *************** ***@posting.goo gle.com>...

Can someone kindly clarify the distinction between long jumps and
gotos? Why is one frowned upon and not the other? Is there really
any situation where use of longjmp becomes inevitable? A real-life
code snippet would surely help.

Regards,
Nimmi

A goto allows you to branch forward or backward within a function.
They are frowned upon because they can destroy the ability to debug
code by inspection. For example, given the code fragment

i = 7;
label: i = i * 4;
printf ("%d\n", i);

there's no guarantee that i will be set to 28 for any given execution
path. The i=7; statement may executed once, or it may never be
executed at all. You have to trace the function line by line and
account for every goto (if any are present) before you can say with
any confidence what value will be written to the screen.

There are cases where they are useful (such as breaking out of deeply
nested loops), but in general they should be avoided in favor of other
control structures (loops, if-else statements, etc.). In 14+ years as
a professional, I've used gotos twice in production code. If you ever
need to use one, use it to branch forward only, and never into a
compound statement (such as a loop or if-else statement).

A longjmp allows you to branch across function boundaries to a
previous calling function. They're useful for aborting out of a
deeply nested function (sort of like throwing an exception in C++).
They don't make as much of a mess wrt debugging as gotos, but they can
make code harder to understand.

[Dan Pop]

In <8b************ *************@p osting.google.c om> ni************* @yahoo.com (Nimmi Srivastav) writes:

Can someone kindly clarify the distinction between long jumps and
gotos?
Try any good book on C.
Why is one frowned upon and not the other?
Neither is frowned upon by the competent programmer, but goto is more
likely to be abused by the incompetent programmer.
Is there really any situation where use of longjmp becomes inevitable?

No, but there are many situations where the use of longjmp greatly
simplifies the code structure. Imagine a program with multiple levels
of menus. Each menu must contain a "return to main menu" option. This
option can be trivially implemented with a longjmp call.

Another popular use is for error handling when the error was detected
deep in the function call chain. Instead of propagating the error back
through all the call chain, up to the function that is supposed to do
something about it, you get there with a single longjmp call.

Try to implement both examples without using longjmp and you'll see that,
although you can live without it, it's a lot more comfortable to live
with it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Heathfield]

[Followups set to comp.lang.c]

Capstar wrote:

This offcourse isn't the end of the world because the system wouldn't
work anyway, but because this system was for a customer it would be nice
to let the application give a proper message saying what happened and
then exit gracefully.

For this purpose I used a setjump right before accessing a board, and a
longjmp in the buserror signal handler. This way the application
wouldn't crash but exit gracefully.

Well, it obviously worked for you, but I think you'll find that calling
longjmp (or, indeed, any library function) in a signal handler invokes
undefined behaviour.

7.1.4 of the C99 Standard says:

4 The functions in the standard library are not guaranteed to
be reentrant and may modify objects with static storage
duration.[158]

[Eric Sosman]

Dan Pop wrote:

[...]
Another popular use is for error handling when the error was detected
deep in the function call chain. Instead of propagating the error back
through all the call chain, up to the function that is supposed to do
something about it, you get there with a single longjmp call.

Try to implement both examples without using longjmp and you'll see that,
although you can live without it, it's a lot more comfortable to live
with it.

Idly wondering ...

jmp_buf bailout;
time_t started_at;

int compare(const void *p, const void *q) {
if (difftime(time( NULL), started_at) > 30.0)
longjmp (bailout, 1);
...
}

...
started_at = time(NULL);
if (setjmp(bailout ) == 0)
qsort (array, count, sizeof array[0], compare);
else
fputs ("Sort was too slow: aborted\n", stderr);

Conforming? (I think so.) Leaking? (I wonder ...)

--
Er*********@sun .com

[Keith Thompson]

Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

[...]
Another popular use is for error handling when the error was detected
deep in the function call chain. Instead of propagating the error back
through all the call chain, up to the function that is supposed to do
something about it, you get there with a single longjmp call.

Try to implement both examples without using longjmp and you'll see that,
although you can live without it, it's a lot more comfortable to live
with it.

Idly wondering ...

jmp_buf bailout;
time_t started_at;

int compare(const void *p, const void *q) {
if (difftime(time( NULL), started_at) > 30.0)
longjmp (bailout, 1);
...
}

...
started_at = time(NULL);
if (setjmp(bailout ) == 0)
qsort (array, count, sizeof array[0], compare);
else
fputs ("Sort was too slow: aborted\n", stderr);

Conforming? (I think so.) Leaking? (I wonder ...)

I don't see a problem with it as far as conformance is concerned.

Performance, however, is likely to be a problem. Unless your
compare() function's normal operation takes a very long time, the time
spent in qsort() is likely to be dominated by calls to time() and
difftime(). A sort that takes too long would likely have worked if
you hadn't tried to measure it.

If I were going to do something like this in real life, I'd probably
add a counter variable and do the time check every N comparisons, for
some suitable value of N.

For a toy example like this, of course, leaving out such bells and
whistles is perfectly appropriate.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Eric Sosman]

[comp.sources.d snipped; this seems very C-specific]

Keith Thompson wrote:

Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

[...]
Another popular use is for error handling when the error was detected
deep in the function call chain. Instead of propagating the error back
through all the call chain, up to the function that is supposed to do
something about it, you get there with a single longjmp call.

Try to implement both examples without using longjmp and you'll see that,
although you can live without it, it's a lot more comfortable to live
with it.

Idly wondering ...

jmp_buf bailout;
time_t started_at;

int compare(const void *p, const void *q) {
if (difftime(time( NULL), started_at) > 30.0)
longjmp (bailout, 1);
...
}

...
started_at = time(NULL);
if (setjmp(bailout ) == 0)
qsort (array, count, sizeof array[0], compare);
else
fputs ("Sort was too slow: aborted\n", stderr);

Conforming? (I think so.) Leaking? (I wonder ...)

I don't see a problem with it as far as conformance is concerned.

Performance, however, is likely to be a problem. Unless your
compare() function's normal operation takes a very long time, the time
spent in qsort() is likely to be dominated by calls to time() and
difftime(). A sort that takes too long would likely have worked if
you hadn't tried to measure it.

If I were going to do something like this in real life, I'd probably
add a counter variable and do the time check every N comparisons, for
some suitable value of N.

For a toy example like this, of course, leaving out such bells and
whistles is perfectly appropriate.

Yes, it's a toy example: I was just trying to concoct some
semi-plausible reason to longjmp() from a callback function to
the original caller, without giving the intermediate function a
chance to clean itself up. For example, a qsort() implementation
might malloc() some memory or acquire other implementation-specific
resources, and if the comparator called longjmp() these would not
be released.

In my opinion, that's the chief drawback of longjmp(): it lets
you "blow past" intermediate levels in the call history without
knowing whether they need to free() memory, fclose() files, or
whatever. Two general approaches seem useful in this regard:

- Wrap up setjmp() and longjmp() with macros and functions
that enforce a more disciplined structure. In particular,
a function that needs to clean things up should have a way
to "intercept" the abnormal unwinding, do its cleaning up,
and then allow the unwind to proceed upwards through other
interceptors (possibly) to the ultimate catcher. You want
not only try/catch, but try/catch/finally.

- Use setjmp() and longjmp() as they are, but only among
functions that are "intimately connected." Perhaps they
should exist in the same source file, or at least share
the same design (c.f. recursive descent parsers). It's
important in this sort of usage to limit the "scope" of
the extraordinary control transfer.

Keep in mind the phenomenon of bit rot, and the problems of
large software edifices. As the code size grows it eventually
reaches the point where nobody, no matter how competent, is able
to understand all the subsystem-local conventions and practices.
Somebody, sometime, *will* change the behavior of some function
and introduce an apparently benign initialize-operate-cleanup
sequence without realizing that somebody else expects to be able
to longjmp() right past the whole shebang:

void do_something(vo id) {
first_thing();
second_thing();
third_thing();
}

in version 1.0 becomes

void do_something(vo id) {
DBHandle *db = connect_to_data base();
start_transacti on(db);
first_thing();
second_thing();
third_thing();
commit_transact ion(db);
close_database_ connection(db);
}

with the addition of the Sooper Dooper Data Snooper in version 3.0,
and if third_thing() decides to call longjmp() ...

It's a tool. It's a tool with no safety catches or blade
guards, because the compiler is usually unable to diagnose only
a very few of its possible misuses. Thus, IMHO, it's a tool to
be used only with great care, and at great need.

--
Er*********@sun .com

[Eric Sosman]

Eric Sosman wrote:

[...] because the compiler is usually unable to diagnose only
a very few of its possible misuses.

Um, er, right. I got myself caught between "able to diagnose
a few" and "unable to diagnose most," and landed somewhere in
the distributed middle. Or the distributed muddle. Sorry
about that, and does anyone have a mail editor that can diagnose
English nonsense?

--
Er*********@sun .com

[Capstar]

Richard Heathfield wrote:

[Followups set to comp.lang.c]

Capstar wrote:

For this purpose I used a setjump right before accessing a board, and a
longjmp in the buserror signal handler. This way the application
wouldn't crash but exit gracefully.

Well, it obviously worked for you, but I think you'll find that calling
longjmp (or, indeed, any library function) in a signal handler invokes
undefined behaviour.

7.1.4 of the C99 Standard says:

4 The functions in the standard library are not guaranteed to
be reentrant and may modify objects with static storage
duration.[158]

.
.
.

[158] Thus, a signal handler cannot, in general, call standard library
functions.

(But note that the footnote, like all footnotes, is non-normative.)

But doesn't that mean that each function doesn't have to be reentrant?
So what I understand is that if I was busy calling longjump from my
program, and then I would get into my signal handler and call longjump
there again I invoke undefined behaviour. Please correct me if I'm wrong
here. But since the signal handler is the only place where I call
longjump, there is no problem with longjump being reentrant or not.

I do believe there are all other side effects of setjmp/longjmp, like
variables being undefined and possible memory-leaks, but thats why I
exit as soon as possible anyway.

Mark

--
<<Remove the del for email>>

[Christian Bau]

In article <bv**********@n ews.tudelft.nl> ,
Capstar <sp***@eg.homei p.net> wrote:

But doesn't that mean that each function doesn't have to be reentrant?
So what I understand is that if I was busy calling longjump from my
program, and then I would get into my signal handler and call longjump
there again I invoke undefined behaviour. Please correct me if I'm wrong
here. But since the signal handler is the only place where I call
longjump, there is no problem with longjump being reentrant or not.

I do believe there are all other side effects of setjmp/longjmp, like
variables being undefined and possible memory-leaks, but thats why I
exit as soon as possible anyway.

The following sequence of events would be quite likely what is intended
to happen:

1. Something exceptional happens.
2. Operating system detects this and goes into "exception handling"
state.
3. OS asks running program whether it can handle the exception (note:
the running program wouldn't necessarily be written in C).
4. As _your_ program was written in C, some library code says that
handles signals sees that you have installed a signal handler. It calls
your signal handler.
5. Your signal handler executes, returns to the library code that called
it, which returns to the operating system.
6. The operating system goes out of "exception handling" state and
continues execution of your program.

If your signal handler calls longjmp, it will never return to the
library code and the operating system, so the OS will still be in
"exception handling" state. Basically, after the longjmp your signal
handler is still running, which could cause all kinds of problems.

[Dan Pop]

In <40************ ***@sun.com> Eric Sosman <Er*********@su n.com> writes:

Dan Pop wrote:

[...]
Another popular use is for error handling when the error was detected
deep in the function call chain. Instead of propagating the error back
through all the call chain, up to the function that is supposed to do
something about it, you get there with a single longjmp call.

Try to implement both examples without using longjmp and you'll see that,
although you can live without it, it's a lot more comfortable to live
with it.

Idly wondering ...

jmp_buf bailout;
time_t started_at;

int compare(const void *p, const void *q) {
if (difftime(time( NULL), started_at) > 30.0)
longjmp (bailout, 1);
...
}

...
started_at = time(NULL);
if (setjmp(bailout ) == 0)
qsort (array, count, sizeof array[0], compare);
else
fputs ("Sort was too slow: aborted\n", stderr);

Conforming? (I think so.) Leaking? (I wonder ...)

By your logic, malloc is evil, too, because it can cause memory leaks *if
misused*.

As usual, there is no substitute for knowing what you're doing and
longjmp is not the right thing when malloc and/or fopen (may) have been
called (without) the corresponding free/fclose calls between the
invocation of setjmp and the longjmp call.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de