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: Tue, 17 Dec 2013 16:46:37 -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> <529F669C dot 6080504 at redhat dot com> <52B01FF5 dot 5090400 at redhat dot com>
On 12/17/2013 04:57 AM, Florian Weimer wrote:
> On 12/04/2013 06:30 PM, Carlos O'Donell wrote:
>> 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.
>
> How likely is that the Austin Group will ever close this ticket, even
> with a indeterminate conclusion like "the standard does not specify
> errno-restoring behavior"? How long should we wait for such a
> resolution? (I think it's too late for this change for 2.19
> anyway.)
If by "close" you mean "fix the language of the standard in some way,"
then it's very likely. However someone needs to drive the process to
get consensus on exactly what language change you want. Repost a final
requested set of changes and ask for agreement? It's just like
in glibc, repost, get consensus, refine, final agreement, and then it
will likely go into Issue 8 of POSIX.
You are right in that I would not want to force through such a change
in 2.19 without at least 6 months of fedora rawhide testing. Such a
change will also require machine changes.
Cheers,
Carlos.