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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>, Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Wed, 20 Nov 2013 16:11:18 +0000
- 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> <20131120073002 dot GA24541 at domone dot podge>
On Wed, 20 Nov 2013, Ondrej Bilka wrote:
> This could be solved by wrapping a handler in function that saves and
> restores errno. You could make functions also safe in this regard or
> decide that implementing solution is too expensive.
The point of an "errno" annotation for AS-safety is that only the user
writing their signal handler can decide whether saving and restoring errno
is the right thing to do in their program, depending on whether the signal
handler calls relevant functions with arguments that might involve a
change to errno and what code might be interrupted by the signal. It's
part of the interface for very many functions, not just in libm, that they
do, or may, set errno, and so many functions that might otherwise be
AS-safe will need such an annotation.
--
Joseph S. Myers
joseph@codesourcery.com