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

 

[Richard Heathfield]

Can someone kindly clarify the distinction between long jumps and
gotos?

The goto construct is a good way to make it hard to read a function, whereas
the longjmp function is a good way to make it hard to read an entire
program.

Why is one frowned upon and not the other?

Because you weren't looking whilst I was frowning at the other.

Is there really
any situation where use of longjmp becomes inevitable?

Not on my watch.

A real-life code snippet would surely help.

Help what? I already /have/ a headache.


All right, let's try to answer this intelligently. Firstly, the basic
difference between them is that longjmp lets you hop around between
functions - or rather, setjmp lets you say "HERE!" and longjmp then
teleports you there later on.

In my experience, it is generally possible, and wise, to manage without
either. Both of them *can* be used wisely, I suppose, but I find it
remarkably easy to do without them.

No doubt there will be some people here who feel differently about it.

 

[E. Robert Tisdale]

Can someone kindly clarify the distinction
between long jumps and gotos?

They really are *not* comparable.

Why is one frowned upon and not the other?

the setjmp/longjpm functions are *not* for new or amateur programmers.

Is there really any situation
where use of longjmp becomes inevitable?

The setjmp/longjmp mechanism
is the way that C programmers "throw" exceptions.
Unfortunately, it does *not* clean-up after you.
Memory allocated from free storage after setjmp
will not be free'd.

A real-life code snippet would surely help.

Take a look at the man page:

http://www.rahul.net/cgi-bin/userbin/man?topic=longjmp&section=3

The following code fragment indicates the flow of control of
the setjmp() and longjmp() combination:

/function declaration/
...
jmp_buf my_environment;
...
if (setjmp(my_environment)) {
/* register variables have unpredictable values */
code after the return from longjmp
...
} else {
/* do not modify register vars in this leg of code */
this is the return from setjmp
...
}

 

[Derk Gwen]

(e-mail address removed) (Nimmi Srivastav) wrote:
# 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.

(1) You can't goto from one function to another. You can longjmp from a
function invocation anywhere upward in the protocol stack.

(2) ANS C doesn't have label variables, but jmp_bufs are variables.

In my recursive ascent parser, error recovery abandons the current parse
before recoverying and restarts from the initial state (more or less).
Rather than have initial function in the parser check on return if a
parse error occurs, I just longjmp from the error detection to the error
recovery.

 

[Christian Bau]

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.

The answer is very simple: If you have to ask what is the difference
between goto and longjmp, then you shouldn't use either of them.

 

[xarax]

The answer is very simple: If you have to ask what is the difference
between goto and longjmp, then you shouldn't use either of them.

He does not necessarily want to *use* them. He wants
to *understand* them. Big difference.

Knowledge is power.

 

[Leor Zolman]

The setjmp/longjmp mechanism
is the way that C programmers "throw" exceptions.
Unfortunately, it does *not* clean-up after you.
Memory allocated from free storage after setjmp
will not be free'd.

Just to be clear, even C++ exception handling doesn't automagically
free up memory allocated from the _free store_ (using new/malloc/etc)
unless some type of smart pointer is inolved. Exception handling only
guarantees that destructors are run for automatic objects that need
them.
-leor



Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Capstar]

Nimmi Srivastav wrote:

In my experience, it is generally possible, and wise, to manage without
either. Both of them *can* be used wisely, I suppose, but I find it
remarkably easy to do without them.

I have used it once. And I didn't know any better way of getting past
this. This was the problem. I had an application running on a VME
system, on which the host needed to communicate to about 8 VME-boards.
The addresses of these boards are set with jumpers, and the hosts has a
configuration file saying which board is at which address.
But when there was a mismatch in the confiuration file and the jumper
settings, the application would get a buserror, which causes it to crash.

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.

But this is indeed for now the only application I used it in.

Just my two cents.

Mark

 

[Richard Bos]

Can someone kindly clarify the distinction between long jumps and
gotos? Why is one frowned upon and not the other?

Both are frowned upon, but beginner programmers aren't likely to abuse
long jumps.

Is there really any situation where use of longjmp becomes inevitable?

I've only encountered one such situation: a dinky-toy compiler made a
long jump necessary.

Richard

 

[Markus Gyger]

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.

A C++ to C translator usually implements exception handling using
[sig]longjmp(). You might need longjmp() to test if some hardware
is there or capable of doing certain things. An example where I
have used longjmp() was to test whether I'm running inside of
VMware or not (it's done by using an instruction that would
raise a SIGSEGV on a native x86 but not on VMware, and you need
the longjmp() to recover from the segmentation violation state).

You can usually "hide" a goto by using break or continue (in
switch or for/while) or simply create an new function and use
multiple return statements (I'm using this when there are a
lot of error checks), this is often easier to understand than
having to work with flags (depends on the application)...


Markus

 

[John Bode]

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]

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

 

[Richard Heathfield]

[Followups set to comp.lang.c]

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]

.
.
.

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

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

 

[Eric Sosman]

[...]
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 ...)

 

[Keith Thompson]

[...]
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.

 

[Eric Sosman]

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

[...]
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(void) {
first_thing();
second_thing();
third_thing();
}

in version 1.0 becomes

void do_something(void) {
DBHandle *db = connect_to_database();
start_transaction(db);
first_thing();
second_thing();
third_thing();
commit_transaction(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.

 

[Eric Sosman]

[...] 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?

 

[Capstar]

[Followups set to comp.lang.c]

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

 

[Christian Bau]

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]

[...]
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