Re: [vox-tech] For "C" gurus
On Thu December 7 2006 08:35, Jeff Newmiller wrote: > 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. Thanks a lot! This is exactly the kind of thing I was looking for. I googled and checked some of my books but didn't find it. The background: The latest version of guile crashed while running a test suite during a debian build on ia64. Since I'm interested in ia64, I took a look at it. This problem with setjmp is just what is causing their problem. I didn't want to post my findings back to their mailing list with out some ammo as to why I couldn't fix it. Richard Harke ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] For "C" gurus
Jeff Newmiller wrote:
Richard Harke wrote:
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.
Wikipedia has a good article on the subject that should scare you away
from using my_wrapper:
http://en.wikipedia.org/wiki/Longjmp
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] For "C" gurus
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 NewmillerThe . . Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/BatteriesO.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] For "C" gurus
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
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
