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: OndÅej BÃlka <neleai at seznam dot cz>
- 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, 03 Dec 2013 12:01:34 -0500
- 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> <20131203161746 dot GA14355 at domone dot podge>
On 12/03/2013 11:17 AM, OndÅej BÃlka wrote:
> 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" <carlos@redhat.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?
A signal handler is allowed to modify errno and return. Is that something
anyone would ever want to do? If we wrap signal handlers to save and
restore errno to avoid this common programming error will it have any
unintended consequences other than slowing things down?
Cheers,
Carlos.