Exceptions in C with Longjmp and Setjmp

http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

by AndreyKarpov • 14 years ago

56 33 14 years ago

di.unipi.it

pagekalisedown• 14 years ago

A practical example of this is libpng:

http://www.libpng.org/pub/png/libpng-1.2.5-manual.html

wulczer• 14 years ago

PostgreSQL also uses longjmp to implement TRY/CATCH macros:

https://github.com/postgres/postgres/blob/master/src/include...

teraflop• 14 years ago

I wouldn't go so far as to call that "practical." It's a cute trick, but it becomes really annoying when trying to write libpng bindings for any environment other than plain C.

hp2• 14 years ago

as someone who has used libpng I'd describe it as an example of why this is a terrible idea.

rbehrends• 14 years ago

A couple of caveats.

First, you rarely want to use setjmp() and longjmp(), but _setjmp() and _longjmp(), or sigsetjmp(..., 0) and siglongjmp(..., 0) to avoid saving and restoring the signal mask. You'll rarely be modifying the signal mask in between, and the additional kernel calls to save/restore the signal mask are pretty expensive.

Second, any function that uses setjmp() or friends should have its variables declared volatile (or at least those that you rely on after executing a longjmp()). Otherwise, you risk that they do not have the proper value after a longjmp(). In particular, variables that are stored in registers and were modified between setjmp() and longjmp() will typically be restored to the value they had when setjmp() has called, not the value they had when you called the function that resulted in a longjmp() (and optimizing compilers may introduce further bugs). Unfortunately, declaring a variable as volatile will typically prevent quite a few optimizations, but it's still necessary for correctness.

rwmj2• 14 years ago

Thirdly: Any malloc'd pointers that are only tracked on the stack end up being lost when you unwind the stack.

This third one makes using longjmp for exceptions almost untenable in real life code. You can make it easier to track and free memory correctly by using a pool allocator for the whole program, which may or may not be realistic, but I once wrote a webserver this way (from scratch, hey it was the 90s).

norswap4• 14 years ago

Wrap malloc in a function that push malloc'ed pointer on a global stack, insert NULL at the point where a try happens. When you throw an exception, simply free everything on the stack until the previous NULL. Problem solved.

Better yet, simply free memory at the exception throw site, if possible.

adgar• 14 years ago

> This third one makes using longjmp for exceptions almost untenable in real life code.

No, it's pretty simple. Postgres does it with something called regions: your code essentially becomes transaction-based, where resources that need cleanup are put into a region associated with a try block, and all remaining resources at the end of the block's (successful or failed) execution are freed. It requires slightly more work than in C++, obviously, because you're not using C++.

malkia• 14 years ago

If you have some C++ code linked, and use RAII (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...) then you won't have the destructors of the objects in the stack getting called. For example if you had a profiling kind of marker, that relies on C++ (instead of begin() end() kind of thing).

apaprocki• 14 years ago

Similarly, jumping forward over C++ objects declared on the stack (also when using goto) will skip their construction.

rcfox4• 14 years ago

I think the requirement of the ETRY macro solidifies this as a neat trick, and not something you actually want to use in a project.

Forget ETRY once and you can kiss your afternoon goodbye while you debug.

daeken3• 14 years ago

Ever left a semicolon off of a struct definition? Forgetting end statements/tokens will frequently lead to debugging pain, but that doesn't make it any less valid. As noted elsewhere, ReactOS uses a very similar structure to great effect.

rcfox4• 14 years ago

Missing a semicolon has a chance of giving a useful error message. Without knowing what ETRY translates to, you have no hope of finding here it's missing.

JoachimSchipper• 14 years ago

On one hand, I agree. On the other, POSIX already has EINTR... (and yes, this does cause lots of bugs.)

norswap4• 14 years ago

It can even go much further than this. I have a version that - supports arbitrarily nested try/catch statement (even in the catch or try parts) - catching multiple exception in each clause - supports exception hierarchy (exception can "inherit" other exceptions)

I'll probably publish it one day, but it needs a little cleaning pass. If you are interested, let me know.

ma2rten• 14 years ago

ReactOS actually makes heavy use of exception handling in C. The wiki page is a bit messy, but here it is: http://www.reactos.org/wiki/PSEH

losvedir• 14 years ago

If you like this article, the book C Interfaces and Implementations[1], goes into this exact technique in great detail, along with many other useful ones.

I picked it up after tptacek recommended it here on HN, and it's definitely worth every penny if you want to do any C programming on a reasonably sized project.

[1] http://www.amazon.com/gp/product/0201498413/

xvolQx• 14 years ago

The current implementation can't be nested...

obtino• 14 years ago

If you're interested in similar implementations, Microsoft has a non-standard try-except statement in their C library: http://msdn.microsoft.com/en-us/library/s58ftw19(v=vs.80).as...

logancapaldo• 14 years ago

That is not a "similar" implementation, and it's not in the "library". It exposes the OS/ABI level exception functionality (which C++ exceptions are also built atop of) to the compiler.

pmr_• 14 years ago

Wasn't exception handling based on longjmp and setjmp abandoned in gcc in favor of dwarf2 especially because the former implementation performs poorly? Does the same approach yield different results for C instead of C++?

hp2• 14 years ago

here is a great post from Owen Taylor in 1999 after this idea was repeatedly raised for the "g" stack on Linux:

http://mail.gnome.org/archives/gnome-list/1999-December/msg0...

it kept coming up, too: http://mail.gnome.org/archives/gtk-devel-list/2001-February/...

Here is what GLib 2.0 ended up with instead, which works well: http://developer.gnome.org/glib/2.31/glib-Error-Reporting.ht...

tptacek• 14 years ago

It's worth mentioning here that exceptions are notoriously unsafe even in C++ programs, where automated ctors and dtors should mitigate these concerns (but inevitably don't because of pointers).

Exceptions in C with Longjmp and Setjmp

Related Stories