Ulf Lamping wrote:
Just out of interest, why is this change needed?
I was looking at the compiler warning before, and didn't get an idea
what the compiler was complaining about.
From the ANSI C89 standard:
4.6.2 Restore Calling Environment
4.6.2.1 The longjmp Function
...
All accessible objects [after the longjmp is done] 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.
and from the Rationale:
The Committee also considered requiring that a call to longjmp restore
the (setjmp) calling environment fully -- that upon executation of a
longjmp, all local variables in the environment of setjmp have the
values they did at the time of the longjmp call. Register variables
create problems with this idea. Unfortunately, the best that many
implementations attempt with register variables is to save them (in
jmp_buf) at the time of the initial setjmp call, then restore them to
that state on each rturn initiated by a longjmp call. Since compilers
are certainly at liberty to change register variables to automatic, it
is not obvious that a register declaration will indeed be rolled back.
And since compilers are at liberty to change automatic variables to
register (if their addresses are never taken), it is not obvious that an
automatic declaration will *not* be rolled back. Hence the vague
wording. In fact, the only reliable way to ensure that a local variable
retain the value it had at the time of the call to longjmp is to define
it with the volatile attribute.