This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Saving errno around signal handlers
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 4 Mar 2014 21:12:23 -0500
- Subject: Re: Saving errno around signal handlers
- Authentication-results: sourceware.org; auth=none
- References: <531077D9 dot 2000308 at redhat dot com> <20140228211938 dot B5FD5744B5 at topped-with-meat dot com> <53143F86 dot 6000201 at redhat dot com> <20140303234207 dot C6ED37444F at topped-with-meat dot com> <531570FE dot 3060100 at redhat dot com>
On Tue, Mar 04, 2014 at 01:21:50AM -0500, Carlos O'Donell wrote:
> On 03/03/2014 06:42 PM, Roland McGrath wrote:
> >> On 02/28/2014 10:19 PM, Roland McGrath wrote:
> >>>> POSIX has green-lighted saving errno around signal handlers.
> >>>
> >>> I don't even know what you might think that means. Whenever talking about
> >>> a change in a standard, provide a reference to the actual change in the
> >>> actual standard.
> >>
> >> It's about this change:
> >>
> >> <http://austingroupbugs.net/view.php?id=807>
> >
> > So the standard is not going to be changed to require that signal handling
> > save and restore errno implicitly. (It would have been a highly suspect
> > change.) It's being clarified to say that the implementation is free to do
> > so. But applications cannot assume any such thing, so any such future
> > application remains as broken as such applications are today. I see no
> > rationale even slightly compelling for making libc do this magic. In fact,
> > it would clearly do harm to people developing applications on glibc-based
> > systems but intending to write POSIX-conformant code.
>
> In that it would mask potential errors in the signal handling code?
In fairness, I believe these errors are already "masked" by being
extremely rare race conditions...
Still, I'm largely against this proposal for an invasive, error-prone,
signal-latency-adding change to glibc just to mask the 0.0001% of
errno+signal handler race conditions that actually reach *buggy*
applications...
Rich