Kaz Kylheku said:
There are two problems with
x = setjmp(...);
One is surmountable; the other isn't.
The first problem is that if x is a variable with automatic storage
which is not volatile-qualified, then the above constitutes an
instance of modifying a non-volatile auto variable after doing a
setjmp, before the longjmp takes place. The value of such a
variable is indeterminate. (See paragraph in description of
longjmp.)
Right, to satisfy the rule above modifying variables x should be
declared volatile if it is local to this function.
The second problem is that when control returns into the setjmp()
expression for a second time via the longjmp invocation, the
setjmp-time environment (all accessible objects) is being restored.
So, imagine that setjmp is being re-activated by a longjmp and is
restoring the value of x:
x = setjmp(...);
But remember that setjmp is not a function, but a macro. It doesn't
have a sequence point between its restoring actions, and the action
of returning a value. So the above constitutes two modifications of
object x without an intervening sequence point.
Of course there is an intervening sequence point. In order to
get to the longjmp() call, program execution had to proceed past
the point of the assignment, which means there was a sequence
point already passed at the end of the full expression containing
the assignment. Just because longjmp() returns to the middle of
the assignment statement doesn't mean it "erases" that sequence
point, any more than it erases any other intervening sequence
points that have occurred.
