Re: setjmp doc fixes

[Bruno Haible]

Eric Blake wrote:
> I was going off of the POSIX 200x draft copy, where they were given OB
> shading (ie. a future version of POSIX may withdraw support for them).

Sure. But that POSIX 200x draft still describes 'setjmp' as having unspecified
behaviour w.r.t. signal mask. They are calling _setjmp "obsolescent", but
at the same time the only non-"obsolescent" to achieve the same thing
- sigsetjmp(.,0) - is always slower than _setjmp. Someone is not doing his
job right here: either the Austin group, or the system implementors.

> Rather, the question (which you should
> probably take up with the Austin group) is whether bypassing the signal
> mask is safe enough to keep without obsoletion, and in which use cases.

There is no question here. sigsetjmp(.,0) is in the standard, and not
"obsolescent". If that is "safe", _setjmp is equally "safe".

> It is certainly NOT safe for use in signal handlers.

Sure, but that's not its main use-case.

> I have no disagreements that _setjmp is still the only documented way to
> save context without wasting time on signal masks, nor that it is likely
> faster than sigsetjmp(,0).

Can you then please fix the gnulib doc to not be so negative about _setjmp/
_longjmp? I propose:

A future revision of POSIX later than the 2008/2009 one may drop the functions
_setjmp and _longjmp. Still, in 2008, on all systems which have _setjmp, it
is the fastest way to save the registers but not the signal mask.

Bruno