🚀 go-pugleaf

I think it is fairly clear that longjmp cannot modify the object
that contains the value that was most recently observed (or set)
through the `errno' accessor (identifier, function call with
indirection, or whatever).

Unfortunately, it is possible, and maybe even ever-so-slightly
sensible, for `errno' to refer to a *different* object on return
from longjmp.  For instance, suppose a compiler elects to put an
`errno' in each activation record (function call stack frame) and
to define `errno' as `the current frame's errno', e.g.,

	#define errno (__builtin_upframe(0)->__errno)

C library functions that set errno would use a different define,
such as:

	#define callers_errno (__builtin_upframe(1)->__errno)

or similar magic to make errors they set visible to their caller.
A compiler that did this would automatically provide `thread-safe'
errno's, because each thread runs on a different stack; moreover,
signal handlers that clobber errno would not destroy the signalled
function's copy.  (I believe this particular excuse for doing
something so complicated is not a good one, but merely present it
as a possiblity.)

Now, in such an implementation, when longjmp unwinds the stack to
the corresponding setjmp, one side effect is that errno will again
refer to the __errno in the frame of the function that called
setjmp, rather than that in the one of the function that called
longjmp.

I never would have thought of this on my own, but it does seem as
though one must copy `errno' to a static-duration variable of one's
own before calling longjmp, if one wishes to preserve it.  (One is
sometimes fascinated by the way English sentences turn out when
one is avoiding the second person, or in this case, the first
person. :-) )
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167