stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <stefan.tele...@gmail.com>
Subject Re: STDCXX-1056 : numpunct fix
Date Fri, 21 Sep 2012 00:59:33 GMT
On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
<cbergstrom@pathscale.com> wrote:

>
> fencepost comment - The results are based on tools and I don't think he has
> a large program which actually triggers the conditions.  (Creating one may
> take quite some time....)

I do have a program which triggers the race conditions:
22.locale.numpunct.mt. Part of the "official" test harness.

The real reason why they don't want to accept what the instrumentation
tools are saying is very simple: they don't LIKE reading what the
tools are saying. So, blame the tools, pretend that "as long as it
doesn't crash again there's no bug" and hope for the best.

Who knows, maybe it won't crash. Maybe it will. Doesn't matter, right?
The official fprintf(3C) debugger says it's thread-safe, so it must
be.

Quite frankly, I am *dismayed* that fprintf(3C) is considered an
acceptable method of debugging thread-safety problems.

You are correct: I did not, and will not, waste my time writing *any*
program which attempts to debug thread-safety problems with
fprintf(3C).

But I am very glad this is on a public mailing list, so everyone can
read what's going on here.


-- 
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com

Mime
View raw message