longjump

[Eric]

Hi ! I just do not understand how longjmp works.. I read this docs :
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.8.html

but I just don't see why the variable value, which the address is not
passed in any argument, changed it's value...

I understood the environnement thing, I think that means all the variables
are saved and then restored using this environnement, but I just don't see
where 'value' changed it's value...


I know using jumps are not a good idea, but I want to have a in-depth
knowledge of the C langage, and all it's obscure corners

Thanks !

 

[Andreas Kahari]

Hi ! I just do not understand how longjmp works.. I read this docs :
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.8.html

but I just don't see why the variable value, which the address is not
passed in any argument, changed it's value...

I think you should leave "addresses" out of this. There are no
pointer in this example.

I understood the environnement thing, I think that means all the variables
are saved and then restored using this environnement, but I just don't see
where 'value' changed it's value...

The variable 'value' changed its value on the line
"value=setjmp(environment_buffer);" in main(), where you landed
after the longjmp() in some_function(). It gets the value 5
since that's the return value of setjmp() that you specified in
the longjmp() call.

 

[Kevin Goodsell]

Hi ! I just do not understand how longjmp works.. I read this docs :
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.8.html

but I just don't see why the variable value, which the address is not
passed in any argument, changed it's value...

I understood the environnement thing, I think that means all the variables
are saved and then restored using this environnement,

No, it does not mean that at all. Variables are not saved or restored by
setjmp or longjmp.

7.13.2.1 The longjmp function

[#3] All accessible objects have values as of the time
longjmp was called, except that the values of objects of
automatic storage duration that are local to the function
containing the invocation of the corresponding setjmp macro
that do not have volatile-qualified type and have been
changed between the setjmp invocation and longjmp call are
indeterminate.

but I just don't see
where 'value' changed it's value...


I know using jumps are not a good idea, but I want to have a in-depth
knowledge of the C langage, and all it's obscure corners

The example isn't even legal:

7.13.1.1 The setjmp macro

[#4] An invocation of the setjmp macro shall appear only in
one of the following contexts:

-- the entire controlling expression of a selection or
iteration statement;

-- one operand of a relational or equality operator with
the other operand an integer constant expression, with
the resulting expression being the entire controlling
expression of a selection or iteration statement;

-- the operand of a unary ! operator with the resulting
expression being the entire controlling expression of a
selection or iteration statement; or

-- the entire expression of an expression statement
(possibly cast to void).

Note that this does not allow a setjmp invocation to appear as the right
side of an assignment expression.

But aside from that, the point is that setjmp may return more than once.
The initial call returns 0. Later, when you invoke longjmp, the effect
is to cause the program to continue executing from the setjmp call
again, but this time with a different return value. So the return value
from setjmp tells you whether it is returning from a direct invocation
or from a later longjmp invocation.

-Kevin

 

[Eric]

ok thanks everyone !

-Eric

Hi ! I just do not understand how longjmp works.. I read this docs :
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.8.html

but I just don't see why the variable value, which the address is not
passed in any argument, changed it's value...

I understood the environnement thing, I think that means all the variables
are saved and then restored using this environnement,

No, it does not mean that at all. Variables are not saved or restored by
setjmp or longjmp.

7.13.2.1 The longjmp function

[#3] All accessible objects have values as of the time
longjmp was called, except that the values of objects of
automatic storage duration that are local to the function
containing the invocation of the corresponding setjmp macro
that do not have volatile-qualified type and have been
changed between the setjmp invocation and longjmp call are
indeterminate.

but I just don't see
where 'value' changed it's value...


I know using jumps are not a good idea, but I want to have a in-depth
knowledge of the C langage, and all it's obscure corners

The example isn't even legal:

7.13.1.1 The setjmp macro

[#4] An invocation of the setjmp macro shall appear only in
one of the following contexts:

-- the entire controlling expression of a selection or
iteration statement;

-- one operand of a relational or equality operator with
the other operand an integer constant expression, with
the resulting expression being the entire controlling
expression of a selection or iteration statement;

-- the operand of a unary ! operator with the resulting
expression being the entire controlling expression of a
selection or iteration statement; or

-- the entire expression of an expression statement
(possibly cast to void).

Note that this does not allow a setjmp invocation to appear as the right
side of an assignment expression.

But aside from that, the point is that setjmp may return more than once.
The initial call returns 0. Later, when you invoke longjmp, the effect
is to cause the program to continue executing from the setjmp call
again, but this time with a different return value. So the return value
from setjmp tells you whether it is returning from a direct invocation
or from a later longjmp invocation.

-Kevin

 

[Andreas Kahari]

Eric wrote: [cut][cut]
The example isn't even legal: [cut]
Note that this does not allow a setjmp invocation to appear as the right
side of an assignment expression.

So you're not allowed to store the return value of setjmp() in
any way?

 

[Richard Bos]

So you're not allowed to store the return value of setjmp() in
any way?

Alas, no. Might've been useful in some cases, but no.

Then again, anything which makes setjmp()/longjmp() less likely to be
used (except excising them) is probably a Good Thing.

Richard

 

[Christian Bau]

Eric wrote: [cut][cut]
The example isn't even legal: [cut]
Note that this does not allow a setjmp invocation to appear as the right
side of an assignment expression.

So you're not allowed to store the return value of setjmp() in
any way?

No. It is very limited what you are allowed to do: If x is an integer
constant expression, then you can use the following types of expressions:

setjmp (env)
! setjmp (env)
setjmp (env) == x
setjmp (env) != x
setjmp (env) >= x
setjmp (env) <= x
setjmp (env) > x
setjmp (env) < x
x == setjmp (env)
x != setjmp (env)
x >= setjmp (env)
x <= setjmp (env)
x > setjmp (env)
x < setjmp (env)

And you can use these as the _complete_ controlling expression of an if,
if/else, switch, for, while, do/while statement. Everything else invokes
undefined behavior.

Basically, setjmp has to store the processor status and longjmp has to
restore it so that execution resumes just after the setjmp call as if
nothing had happened. This can be simple on some architecture, but
difficult on another one. The C Standard must make sure that everything
can be implemented on any reasonable machine, so a compiler for an
architecture where setjmp is difficult to implement only needs to
produce correct code for this very small number of cases.

It is quite possible that with your compiler, much more complicated uses
of setjmp will work, but it wouldn't be portable. It is also possible
that on very common architectures certain complicated uses of setjmp
would be extremly difficult to implement. I can't think of such a case
at the moment, but setjmp/longjmp is tricky and it is quite possible
that there are such cases. If that were true, then the C Standard would
most likely make these complicated cases undefined behavior. But that
would be very complicated to do in the C Standard, so this simple set of
rules is better.

(What is quite interesting is that even very simple cases like
setjmp (env); /* Not inside a selection or iteration statement */
if (1 && setjmp (env)) { ... }
if (! (setjmp (env) == 0)) { ... }
invoke undefined behavior. )

 

[Johan Aurer]

(What is quite interesting is that even very simple cases like
setjmp (env); /* Not inside a selection or iteration statement */
if (1 && setjmp (env)) { ... }
if (! (setjmp (env) == 0)) { ... }
invoke undefined behavior. )

No, the first one is correct. See 7.6.1.1, "Environmental constraint."

 

[Johan Aurer]

Alas, no. Might've been useful in some cases, but no.

Well, if the set of possible return values is fairly small, you could use
a switch statement:

int err;

switch (setjmp(env)) {
case 0:
err = 0;
break;
case 1:
err = 1;
break;
case 2:
err = 2;
break;
case 3:
err = 3;
break;
}

 

[Dan Pop]

Eric wrote: [cut][cut]
The example isn't even legal: [cut]
Note that this does not allow a setjmp invocation to appear as the right
side of an assignment expression.

So you're not allowed to store the return value of setjmp() in
any way?

Right. The restrictions imposed by 7.13.1.1p4 may seem strange,
but they were carefully written to allow implementing the setjmp
macro on all the platforms in current use back when C89 was drafted.

Dan

 

[Irrwahn Grausewitz]

No, the first one is correct. See 7.6.1.1, "Environmental constraint."

Since I'm unable to locate a section numbered 7.6.1.1 in either C89 or
C99, and the example exceeds the environmental limits imposed by C99
7.13.1.1#4, could you please elaborate on this?

Regards

 

[Jeremy Yallop]

(What is quite interesting is that even very simple cases like
setjmp (env); /* Not inside a selection or iteration statement */ [...]
invoke undefined behavior. )

That's "the entire expression of an expression statement", which is
one of the valid contexts for a setjmp invocation.

Jeremy.

 

[Irrwahn Grausewitz]

Since I'm unable to locate a section numbered 7.6.1.1 in either C89 or
C99, and the example exceeds the environmental limits imposed by C99
7.13.1.1#4, could you please elaborate on this?

Sorry, forget about what I've written. I misread Christians comment
in the first example, you are right, Johann. My apologies for
messing up. (However, there's still no section 7.6.1.1, AFAICT).

Regards

 

[Dan Pop]

Since I'm unable to locate a section numbered 7.6.1.1 in either C89 or
C99, and the example exceeds the environmental limits imposed by C99
7.13.1.1#4, could you please elaborate on this?

It's the right C90 section number for the setjmp macro.

Dan

 

[Irrwahn Grausewitz]

Irrwahn Grausewitz <[email protected]> writes:

It's the right C90 section number for the setjmp macro.

Ahh, Ok, I see. Unfortunately I only own a draft of C89 and copies
of C99 and C99:TC1.

Thanks & Regards