setjmp/longjmp

Henry Spencer henry at utzoo.uucp
Sun Apr 30 09:26:32 AEST 1989


In article <17179 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>>... in the general case [getting variables right after setjmp/longjmp is]
>>very hard.
>
>It is not *that* hard...

Depends on your environment.  If you are free to pick your own calling
conventions, in particular, it's not a big deal.  If you are constrained
by existing conventions, though, it can be pretty tricky, especially
in a dumb compiler.

>>... a very clever compiler can change save/restore conventions when
>>it notices the setjmp() ....
>
>This is a reasonable approach.  setjmp/longjmp are rare enough that I
>doubt it will slow things much.

I and others argued, as formal public comments, that odd behavior of
local variables should be restricted to variables declared "register",
on the grounds that the only real problem is silent promotion of non-
"register" variables into registers, and compilers that are smart enough
to do that are smart enough to notice setjmp and change conventions.
(Dumb compilers may be generating code on the fly, meaning that they
can't easily go back and fix earlier code on seeing setjmp(), but such
compilers generally wouldn't have enough info to promote variables.)
People are more or less used to problems with "register" variables after
longjmp; extending it to all local variables breaks a lot of programs.

Furthermore, if you look at the exact wording in the (draft) standard,
it says that only the variables in the function that called setjmp()
can be fouled up.  In particular, locals in a calling function can't be.
At first glance, satisfying this seems to be almost as hard as "doing
it right":  the setjmp()ing function has to protect any registers its
caller is using, so it might as well protect its own too.  Conventions
that guarantee that no caller registers are in use also usually guarantee
no problems on longjmp().
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.std.c mailing list