Re: setjmp, sigsetjmp, siglongjmp,_setjmp

["J.T. Conklin" <jtc%cygnus.com@localhost>]

>>>>> "Ignatios" == Ignatios Souvatzis <is%beverly.rhein.de@localhost> writes:
Ignatios> a) you seem to be right; a quick glance at the library
Ignatios> source code tells me only the integer part of the cpu is
Ignatios> saved.
Ignatios>
Ignatios> b) the manual page doesn't mention anything special.
Ignatios>
Ignatios> c) i386 doesn't save FP, either.
Ignatios>
Ignatios> d) in contrast, the ALPHA code does save it, as far as I can
Ignatios> understand its assembler code.
Ignatios> this. 

Ignatios> JTC? What do the standards say about 1., and maybe 2.?

The C standard is very loose about how much context must be saved by
setjmp and restored by longjmp.  About the only requirement is that
variables declared with the volatile qualifer must retain their values
after control is returned by longjmp().

Some longjmp/setjmp implementations save nothing more than the PC, BP,
and SP; others save non-clobbered integer registers; some both integer
and floating point registers, and some store the registers and full
FPU context.

It's clear to me that there is not a "right answer".  It comes down to
the programmer's expectations.  In the setjmp/longjmp implementations
I've written for Cygnus' libc, I save the minimal context because no
programmer can expect more and our (embedded) customers favour small
fast code.

I haven't studied all the issues, but I think it's possible to go too
far when it comes to saving context.  If you provide a primitive which
saves the minimal context, it is rather trivial to build upon that to
save more.  It is difficult when something saves too much.  

For example, if the entire FPU state is saved, the current rounding
and precision modes will be reset too.  This may not be what the
programmer expects.

        --jtc