This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 04 Dec 2013 12:30:04 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311182312130 dot 8831 at digraph dot polyomino dot org dot uk> <528BA2DA dot 3090608 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311192205550 dot 8742 at digraph dot polyomino dot org dot uk> <20131120204655 dot GL24286 at brightrain dot aerifal dot cx> <5295CD1D dot 7080501 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311271329590 dot 5027 at digraph dot polyomino dot org dot uk> <5295F7A3 dot 9050209 at redhat dot com> <5298243E dot 5050401 at redhat dot com> <20131129175805 dot GF24286 at brightrain dot aerifal dot cx> <529DE17E dot 7010105 at redhat dot com> <529DF84C dot 5050204 at redhat dot com> <529F08E7 dot 6010701 at redhat dot com>
On 12/04/2013 05:50 AM, Florian Weimer wrote:
> On 12/03/2013 04:27 PM, Carlos O'Donell wrote:
>
>> I think that's certainly the right start. File a defect with the
>> Austin Group tracker and ask them the following things:
>>
>> * What if any unintended consequences could there be if the
>> implementation choose to save and restore errno during
>> signal handling?
>>
>> * Was it ever POSIX's intent to allow a signal handler to
>> modify the errno of the interrupted code sequence or was
>> that simply a consequence of being a signal handler and
>> modifying global state?
>>
>> ... and anything else you think we should get an expert opinion
>> on before embarking upon a change like this.
>
> Okay, I tried to summarize the previous discussion there:
>
> <http://austingroupbugs.net/view.php?id=807>
Interesting response from Geoff Clare:
"If we make any change as a result of this issue, I think it should
just be to make it explicit that implementations are allowed, but
not required, to restore errno on return from signal handlers."
Which would be a nice addition and clarification to the standard.
Good work! Keep pushing this forward and we might kill a whole class
of ugly bugs :-)
Cheers,
Carlos.