This is the mail archive of the
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, Florian Weimer <fweimer at redhat dot com>, Rich Felker <dalias at aerifal dot cx>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Tue, 3 Dec 2013 17:17:46 +0100
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <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> <87pppej64d dot fsf at igel dot home> <529DFDA2 dot 1050004 at redhat dot com>
On Tue, Dec 03, 2013 at 10:49:54AM -0500, Carlos O'Donell wrote:
> On 12/03/2013 10:39 AM, Andreas Schwab wrote:
> > "Carlos O'Donell" <email@example.com> writes:
> >> * 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?
> > <http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.htm>:
> > Note in particular that even the "safe" functions may modify errno; the
> > signal-catching function, if not executing as an independent thread,
> > should save and restore its value in order to avoid the possibility that
> > delivery of a signal in between an error return from a function that
> > sets errno and the subsequent examination of errno could result in the
> > signal-catching function changing the value of errno.
> It isn't clear from this statement, which I've read before, if it was
> ever intended that such error changing behaviour be allowed.
> Did POSIX purposely allow signal handlers to change errno because they
> saw a use case that required it or was it simply a performance choice
> to allow signal handlers to avoid the penalty of saving and restoring
> the thread-local value?
A text above is recomendation of saving errno. How that implies that
returning errno by signal handler is allowed?