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: Torvald Riegel <triegel at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>
- Date: Sat, 23 Nov 2013 00:47:48 +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> <orob5fv8nl dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311201555320 dot 28804 at digraph dot polyomino dot org dot uk> <orli0itbm5 dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311211322040 dot 14539 at digraph dot polyomino dot org dot uk> <or4n75t4b7 dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311221324200 dot 5029 at digraph dot polyomino dot org dot uk> <orob5csdvx dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311221535560 dot 8443 at digraph dot polyomino dot org dot uk> <1385158981 dot 3152 dot 2785 dot camel at triegel dot csb>
On Fri, 22 Nov 2013, Torvald Riegel wrote:
> > Documenting limitations of safety only makes sense if we wish to support
> > use of the function in a particular context provided the user follows
> > particular rules. In this case, and probably many cases for AS-Safety, I
> > think we should just say AS-Unsafe - we don't want to support this in
> > signal handlers at all, under any circumstances, and so don't need to
> > document anything about what makes it unsafe, just that it is unsafe.
>
> I'd prefer if we'd put macros with this information into the
> documentation, even if we should choose to let them expand to empty
> strings. Right now, I don't see much of a benefit of maintaining the
> reasons somewhere external.
I'm happy with some cases expanding to nothing - but if the conclusion
from the reasons given is either "fundamentally unsafe with the current
implementation" (e.g. malloc in signal handlers, even if we don't know if
the function really should be using malloc) or "fundamentally unsafe and
we don't intend to change that", I don't think the *formatted manual*
should give detailed reasons, just the statement of lack of safety and the
indication of whether this is the intended API or just information about
the current implementation.
--
Joseph S. Myers
joseph@codesourcery.com
- References:
- Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.
- Re: Consensus on MT-, AS- and AC-Safety docs.