Re: Saving errno around signal handlers

["Joseph S. Myers" <joseph at codesourcery dot com>]

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