This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Saving errno around signal handlers


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.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]