(On using longjmp in place of some form of built-in exception
handling...)
Fair enough; longjmp cannot call destructors automatically like
C++/Java/etc exceptions can but it *can* unwind the stack.
Well, maybe. "Can" is sometimes architecture-dependent, and
"does" is not actually true on many real implementations.
The jmp_buf initialised with setjmp only gets invalidated when the
function scope where setjmp is called returns[1]. I'd assume that,
with language support for destructors (variables going out of
scope automatically get a certain function called), exceptions
can be implemented with longjmp.
It is more complicated than that: in languages like Lisp (with
unwind-protect) and C++ (with destructors), you *must* "unwind
the stack", and transfer control (or act "as if" you had) to
those points at which runtime action is to be taken.
There are a lot of ways to implement this, but they all have some
costs, either in runtime for all functions, or in executable and/or
runtime-image space, or both. Since C lacks the requirement for
"one frame at a time unwinding", C implementations can save the
space and/or time -- and many do.
How is this different from exceptions? I might be way off here, but I
always assumed that exceptions could only unwind the stack, not magically
unlock or call free (or delete).
In a language that supports exceptions and has destructors (like
C++), the "unwind sequence" in longjmp() looks something like
this:
void longjmp(jmp_buf buf, int value) {
struct frame *fp = some_sort_of_magic();
struct frame *target_frame = more_magic(buf);
if (value == 0)
value = 1;
while (fp != target_frame) {
if (fp == NULL)
panic("bad call to longjmp");
if (fp->flags & UNWIND_ACTION)
(*fp->unwind)(fp);
fp = fp->prev_frame;
}
yet_more_magic(buf, value); /* resume at setjmp, returning "value" */
}
In C, it often looks instead like this:
void longjmp(jmp_buf buf, int value) {
if (value == 0)
value = 1;
magic(buf, value); /* resume at setjmp, returning "value" */
}
Note that the C++ "longjmp" is much heavier-weight, and requires
every function-call to set up fp->flags and (if the flags include
"take action on unwind") fp->unwind.
In both cases, the final magic sets the frame and/or stack pointers.
On some architectures, there is no separate "frame pointer", and
each subroutine can make up its own "virtual frame". If this
is carried through to the C++-style longjmp, the longjmp() code
becomes substantially more convoluted, as the last line of the
loop becomes:
while (fp != target_frame) {
...
fp = reconstruct_previous_frame(fp);
}
where "reconstruct previous frame" is arbitrarily complicated (it
may have to look in a table to correlate a "program counter" value
with a "function address range", then use that to find a "virtual
frame pointer offset" given a saved-stack-pointer; this is how it
works on MIPS processors for instance).
The shorter, C-specific "longjmp" remains unchanged, even on the
MIPS. (The jmp_buf can simply record the stack pointer and PC.
Going to the target PC automatically restores the virtual frame
pointer. Or, usage of setjmp() may force an actual frame pointer,
just like using a C99 VLA. In this case the "now-real" fp register
can be stored in the jmp_buf, along with the always-real sp. Note
that in either case, longjmp()ing wipes out VLAs allocated after
the call to setjmp().)
