Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is setjmp/longjmp ok?

Reply
Thread Tools

Is setjmp/longjmp ok?

 
 
Michael B Allen
Guest
Posts: n/a
 
      05-01-2004
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
 
Reply With Quote
 
 
 
 
-wombat-
Guest
Posts: n/a
 
      05-01-2004
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.
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      05-01-2004
On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <(E-Mail Removed)>
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
 
Reply With Quote
 
-wombat-
Guest
Posts: n/a
 
      05-02-2004
Jack Klein wrote:

> On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <(E-Mail Removed)>
> 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.

 
Reply With Quote
 
Michael B Allen
Guest
Posts: n/a
 
      05-02-2004
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
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-03-2004
-wombat- <(E-Mail Removed)> wrote:

> Jack Klein wrote:
>
> > On Fri, 30 Apr 2004 20:51:10 -0700, -wombat- <(E-Mail Removed)>
> > 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
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      05-03-2004

In article <(E-Mail Removed) >, Michael B Allen <(E-Mail Removed)> 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 http://www.velocityreviews.com/forums/(E-Mail Removed)

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
 
Reply With Quote
 
-wombat-
Guest
Posts: n/a
 
      05-03-2004
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.
 
Reply With Quote
 
Alan Balmer
Guest
Posts: n/a
 
      05-03-2004
On Sun, 02 May 2004 00:00:04 -0400, Michael B Allen
<(E-Mail Removed)> 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
(E-Mail Removed)
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      05-04-2004
Alan Balmer wrote:
> Michael B Allen <(E-Mail Removed)> 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments