This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Saving errno around signal handlers
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 3 Mar 2014 18:16:05 +0000
- Subject: Re: Saving errno around signal handlers
- Authentication-results: sourceware.org; auth=none
- References: <531077D9 dot 2000308 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1402282205090 dot 17634 at digraph dot polyomino dot org dot uk> <53144486 dot 4030108 at redhat dot com>
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