rationale for obsoleting _setjmp

[Eric Blake <ebb9@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Haible pointed out on the CLISP mailing list that many
implementations of _setjmp/_longjmp are faster than the corresponding
sigsetjmp(,0)/siglongjmp:
http://article.gmane.org/gmane.lisp.clisp.devel/18227

All I could find about marking _setjmp obsolescent was this message:
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9760

which only mentions the action without any corresponding rationale behind
the action.  Yes, it is true that _setjmp/_longjmp cannot be used to
return from signal handlers, but there are other scenarios where it can be
useful.  It is the only documented interface in POSIX that guarantees that
the implementation will not spend time saving the signal mask.  Can anyone
point to better rationale for why it was marked OB in the current draft?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhKBIUACgkQ84KuGfSFAYAHrQCg2HaIOBW1IgsGr9bhtmsO0e3X
Xv8AnA6/ez0v8t2UH2CPwkJAJwNX886C
=9l23
-----END PGP SIGNATURE-----