Behaviour of setjmp/longjmp and registers

Henry Spencer henry at utzoo.uucp
Mon Jan 23 10:58:59 AEST 1989


In article <7222 at polyslo.CalPoly.EDU> cquenel at polyslo.CalPoly.EDU (96 more school days) writes:
>Assuming that volatile variables are written out to memory
>before any procedure call.  (Even if this is not sufficient,
>assume that volatile variables have been dealt with.)
>
>Should it ever be necessary/desirable to restore any registers
>on a long-jump BESIDES the frame-pointer and/or stack-pointer ?

Assuming that any other registers needed by the compiler -- not all
implementations get by with just an FP and SP -- have been dealt with,
ANSI C conformance doesn't require anything more.

However, an implementation that simply trashes the registers (rather,
allows them to be trash) or, still worse, does likewise for automatic
variables not declared "register" (i.e. by promoting them to registers
and then not preserving them), is probably not going to sell well when
word gets around.  The old de-facto rule was that register variables
had either current values or values as of the setjmp call, and that
other automatics weren't touched at all.  Minimal ANSI conformance
will thus break essentially every longjmp-using program in existence.
Don't expect the customers to be too delighted about that.  Your best
quick solution is to save all registers at setjmp time and then restore
them at longjmp time, and avoid promoting automatic variables.  The
preferred solution, more work, is to notice the use of setjmp (there
are enough restrictions on it that you can do that) and save/restore
everything around all function calls within a function that uses
setjmp.
-- 
Allegedly heard aboard Mir: "A |     Henry Spencer at U of Toronto Zoology
toast to comrade Van Allen!!"  | uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.lang.c mailing list