This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 10 Jun 2013 09:19:12 +0200
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb> <ora9nrh1cz dot fsf at livre dot home> <1369592301 dot 16968 dot 3046 dot camel at triegel dot csb> <orehcoqm0d dot fsf at livre dot home> <1370363818 dot 16968 dot 11024 dot camel at triegel dot csb> <orsj0ur1nu dot fsf at livre dot home> <1370610034 dot 16968 dot 11295 dot camel at triegel dot csb> <51B349B4 dot 7050304 at redhat dot com>
On 06/08/2013 05:11 PM, Carlos O'Donell wrote:
The complexity of the topic is so high that a mistake on our part
could have us document something that is later incompatible with
Issue 8 of POSIX.
Do you suggest to deliberately make our documentation ambiguous instead,
so that we can blame other programmer when we make incompatible changes
required by POSIX 8?
Sorry, but this whole discussion appears increasing surreal to me.
Library documentation should be useful to programmers. Certainly,
precise documentation combined with a backwards compatibility promise
constrains future implementation choices. But without detailed
documentation, programmers (and other documentation authors) will guess
what the intended interface is, perhaps even consult the source code,
and program against an imagined interface.
For example, the claim that there is no memory barrier implied by
passing a byte down a pipe is most unsettling.
The consequence of an incompatibility with POSIX is so terrible
that what you argue is too risky a path to take.
On the other hand, if we don't document interface guarantees which are
implicitly required by applications programs today, this will weaken our
position (and force us to eventually adopt changes which are de facto
backwards-incompatible) in the POSIX 8 standardization, won't it?
--
Florian Weimer / Red Hat Product Security Team