Christian Henning wrote:
Hi Phil, let's start at the beginning:
Next we clean up and issue an exception. Hope this makes sense. No, it doesn't make sense. Sorry if I am missing something important. Maybe someone else would like to have a look at this code? It's here: http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/... near the start of the file.
My understanding setjmp/longjmp is this:
#include <iostream> #include <csetjmp>
static jmp_buf mark;
void try_something() { if( setjmp( mark )) { std::cout << "we are back" << std::endl; } }
void error_exit() { std::cout << "ups we had a problem" << std::endl; longjmp( mark, 1 ); }
int main( int argc, char* argv[] ) { try_something(); error_exit();
return 0; }
When error_exit is called we are jumping back to where setjmp was called before.
Do you agree that's the correct behavior?
I agree with Phil; that's undefined behaviour. I can't access the official C standard here, but in the C99 draft N1256 (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), in 7.13.2.1p2, it says (of longjmp): ... if the function containing the invocation of the setjmp macro has terminated execution in the interim, ... the behavior is undefined. So, once try_something has returned, the effect of calls to longjmp is undefined. John Bytheway
