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: Fri, 28 Feb 2014 22:12:47 +0000
- Subject: Re: Saving errno around signal handlers
- Authentication-results: sourceware.org; auth=none
- References: <531077D9 dot 2000308 at redhat 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