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: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 04 Dec 2013 11:50:15 +0100
- 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>
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>
--
Florian Weimer / Red Hat Product Security Team