This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Saving errno around signal handlers
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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, 04 Mar 2014 23:31:34 -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> <20140305021223 dot GI184 at brightrain dot aerifal dot cx>
On 03/04/2014 09:12 PM, Rich Felker wrote:
> 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...
Neither of us have data, at least none that I've seen, to backup either
side of the claim.
Cheers,
Carlos.