Is setjmp/longjmp ok?

[Michael B Allen]

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

[-wombat-]

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

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.

[Jack Klein]

On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <sc****@cs.ucla.edu>
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/~a...FAQ-acllc.html

[-wombat-]

Jack Klein wrote:

On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <sc****@cs.ucla.edu>
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.

[Michael B Allen]

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

[Richard Bos]

-wombat- <sc****@cs.ucla.edu> wrote:

Jack Klein wrote:

On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <sc****@cs.ucla.edu>
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

[Michael Wojcik]

In article <pa**********************************@ioplex.com >, Michael B Allen <mb*****@ioplex.com> 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 mi************@microfocus.com

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

[-wombat-]

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.

[Alan Balmer]

On Sun, 02 May 2004 00:00:04 -0400, Michael B Allen
<mb*****@ioplex.com> 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
re************************@att.net

[CBFalconer]

Alan Balmer wrote:

Michael B Allen <mb*****@ioplex.com> 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.

[Richard Bos]

-wombat- <sc****@cs.ucla.edu> 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

[-wombat-]

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.