Saving errno around signal handlers
Joseph S. Myers
joseph@codesourcery.com
Fri Feb 28 22:12:00 GMT 2014
On Fri, 28 Feb 2014, Florian Weimer wrote:
> POSIX has green-lighted saving errno around signal handlers. So the question
> now is how we implement that.
I presume you mean that it's been decided that it's permitted to save
errno (permitted in the current standard, as opposed to a development
direction for a future major revision of POSIX) - not that it's required
to do so.
So the first question is whether we should take advantage of that POSIX
permission at all. This seems similar to other cases of programs having
undefined behavior, where we don't try to make them do anything sensible,
such as not checking for invalid pointer arguments. Maybe there should be
a non-default optional sigaction flag SA_SAVEERRNO (allocation of this
flag value would of course need coordinating with the kernel), and
_FORTIFY_SOURCE or similar could then map sigaction calls to a non-default
variant that always uses this flag (it's not clear this is really within
the scope of _FORTIFY_SOURCE, though)?
> * kernel-based solutions
These generally seem less fragile.
> We could a flag which replaces SA_RESTORER and switches on this callback
> behavior for a specific signal handler, using the existing sa_restorer field
> as the address of the wrapper function.
This one in particular would allow things to be controlled by a sigaction
flag as suggested above.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list