This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread-, Signal- and Cancellation-safety documentation


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]