[MTASCsft PATCH WIP5 01/33] Multi Thread, Async Signal and Async Cancel safety documentation: intro
Joseph S. Myers
joseph@codesourcery.com
Tue Nov 19 01:49:00 GMT 2013
On Mon, 18 Nov 2013, Carlos O'Donell wrote:
> On 11/13/2013 07:57 AM, Joseph S. Myers wrote:
> > On Wed, 13 Nov 2013, Alexandre Oliva wrote:
> >
> >> +@item @code{simfpu}
> >> +@cindex simfpu
> >> +
> >> +Functions annotated with @code{simfpu} may misbehave on powerpc ports in
> >> +which the floating-point unit is disabled and floating point simulation
> >
> > Reviewing <https://sourceware.org/ml/libc-alpha/2013-11/msg00189.html>,
> > and <https://sourceware.org/ml/libc-alpha/2013-11/msg00180.html> on which
> > it depends, would be better than documenting the bug....
>
> The adverb better should be associated with some kind of improvement
> e.g. better that we have less defects instead of more detailed documentation.
>
> While I agree that it is always better from a quality perspective to fix
> bugs instead of documenting them, the problem is that Alex's goal here is
> not to fix the bugs but to document several attributes for all functions
> in the library.
When considering a patch that we know is not the right solution to
something and parts of which are likely to need reverting as part of the
right solution, I think the relevant consideration is how soon that
reversion is likely to be needed.
In this case, the proper solution already exists and so the reversion is
likely to be needed soon. That is very different from the async signal
safe TLS patches, which could well largely be made obsolete by a proper
fix for bug 16134 (ensuring TLS allocation failure results in
pthread_create or dlopen failure) but where there is no indication of
anyone currently working on such a fix.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list