[vox-tech] For "C" gurus

Richard Harke rharke at earthlink.net
Wed Dec 6 21:35:08 PST 2006


I have seen something like the following to describe
how setjmp/longjmp is used, though asub is likely
to represent a complicated tree of calls with
a variety of potential failure points, with longjmp
being the quick and easy way out.

int
asub(jmp_buf env)
{
.....do something
	longjmp(env, 1);
}

int
main()
{
	jmp_buf env;
/*init*/
some code
     if (setjmp(env);) {
/* returned from longjmp */
        clean up
        exit(0);
	} else {
/*just returned from setjmp */
	asub(env);
        may not return
	}
}

But suppose this is changed to the following:

int
asub(jmp_buf env)
{
.....do something
	longjmp(env, 1);
}

int
my_wrapper(jmp_buf env)
{
	int x;

	if (x = setjmp(env)) {
	     return x;
	 } else {
            return 0;
	 }
int
main()
{
	jmp_buf env;
/*init*/
some code
     if (my_wrapper(env);) {
/* returned from longjmp */
        clean up
        exit(0);
	} else {
/*just returned from setjmp */
	asub(env);
        may not return
	}
}

Notice that because we returned from my_wrapper before
calling asub, the local variables for asub have been
removed from the stack. Thus they cannot be restored
by the longjmp. It seems to me this usage should
be explicitly rejected. Can any one point me to an
authoratative reference that says this?

Richard Harke


More information about the vox-tech mailing list