Re: Saving errno around signal handlers

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Mar 03, 2014 at 06:16:05PM +0000, Joseph S. Myers wrote:
> On Mon, 3 Mar 2014, Florian Weimer wrote:
> 
> > On 02/28/2014 11:12 PM, Joseph S. Myers wrote:
> > 
> > > 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)?
> > 
> > Making this opt-in is not very attractive because once you touch application
> > sources to deal with this, you could just fix the signal handler.
> 
> Having a feature test macro like _FORTIFY_SOURCE avoids the issue of 
> touching application sources (presuming you have a global place to 
> configure such build options for a distribution).
> 
> (Given that _FORTIFY_SOURCE is at least mainly about buffer size checks, 
> however, I don't know if other checks or fixups for erroneous uses of 
> interfaces - which is what this is - should necessarily go under the same 
> macro rather than a new one.)

I think _FORTIFY_SOURCE is the right place for all
potentially-expensive checks that turn undefined behavior into
predictable crashes. However in the case of this signal handler &
errno business, it seems the goal is to mask the undefined behavior
(by giving the behavior the application expected) rather than trapping
and reporting it, so _FORTIFY_SOURCE is probably the wrong place to
put it (and I'm still not convinced this behavior should be
implemented at all).

Rich