Re: [PATCH] plot.c, setjmp question

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 02 June 2007 14:00, Timoth=C3=A9e Lecomte wrote:
>=20
> So, I conclude that any code executed conditionally to !setjmp(...), if
> not changing the stack, could be put before the call to setjmp and give
> exactly the same behaviour. In other words:
>=20
> if(!setjmp(...))
> {
>     /* setjmp returns direclty */
>     code_that_does_not_change_the_stack();
> }
> else
> {
>     /* coming back from longjmp */
> }
>=20
> is strictly equivalent to:
>=20
> code_that_does_not_change_the_stack();
> if(setjmp(...))
> {
>     /* coming back from longjmp */
> }
>=20
> Am I right ?

I'm not certain, but I don't think this is correct.

=46or one thing, SETJMP actually translates to sigsetjmp(env, save_signals).
So both the stack and the signal state must remain unchanged.

=46or another, consider what happens if there is an error return from=20
the initialization code.

Here's the actual code:

    if (!SETJMP(command_line_env, 1)) {
        /* first time */
        interrupt_setup();
        get_user_env();
        init_loadpath();
	...
    } else {
        /* come back here from int_error() */

But interrupt_setup() presumably changes the signal-handling state,
so it cannot be moved ahead of SETJMP without changing the environment
restored after longjmp().

And if something inside init_loadpath() attempted an error return
via longjmp() then you would get an infinite loop if you move the
call ahead of SETJMP.  I don't think init_loadpath() in fact can=20
trigger this, but it's something you have to worry about in general.


=2D-=20
Ethan A Merritt