Richard Harke wrote:
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?
I don't have the latest standard, but this is covered in ANSI X3.159-1989
Section 4.6.2.1 lines 7-10:
The longjmp function restores the environment saved by the most recent
invocation of the setjmp macro in the same invocation of the program, with
the corresponding jmp_buf argument. If there has been no such invocation,
or if the function containing the invocation of the setjmp macro has
terminated execution in the interim, the behavior is undefined.
--
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
_______________________________________________
vox-tech mailing list
[email protected]
http://lists.lugod.org/mailman/listinfo/vox-tech
