Ambiguity in definition of setjmp/longjmp makes them much less useful

[Henry Spencer]

In article <1597 at redsox.bsw.com> campbell at redsox.bsw.com (Larry Campbell) writes:
>My real question is this:  Why not define the behavior of setjmp/longjmp so
>that the values of ALL local variables are defined, whether or not they've
>been allocated to registers? ...

Because it is painful to implement in certain situations, and there are
many existing compilers that punt said situations as a result.

One would really like longjmp to act much like a multi-level return.  This
is hard, because there may be saved register values on the stack which would
have to be restored.  If the format of the stack frame is fixed (pdp11) or
self-describing (VAX), this is easy enough... but on modern machines you
have neither of those happy situations, and it can be arbitrarily hard to
figure out which parts of the stack represent values that should be put
back into registers.  (You don't want to incur overhead on every function
call just because somebody might someday call longjmp.)

ANSI C puts enough constraints on setjmp that a smart compiler can notice
a call to it, and bracket other calls from that function with a special
save-return sequence so that stack unravelling is not needed.  Unfortunately,
this really requires a compiler that compiles a whole function at a time,
and many simple or fast compilers compile a statement at a time.

Some implementations restore all the registers to the way they were when
the *setjmp* was called, but this is often unsatisfactory in general and
can be very unsatisfactory when compilers really start playing games with
register usage.

Said register-usage games also make it impractical to specify behavior
that depends on whether the programmer explicitly declared things "register".
(Although some of us tried to point out that the set of compilers which *do*
play register games but *don't* compile whole functions at a time must be
pretty small, so it would not be a disaster to require the register-game
compilers to do call bracketing.  Alas, our wise words :-) were not heeded.)

There just ain't no graceful way.
-- 
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry at zoo.toronto.edu   utzoo!henry