stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <>
Subject Re: STDCXX-1056 : numpunct fix
Date Thu, 20 Sep 2012 21:23:43 GMT
On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
<> wrote:

>> I'll let you in on a little secret: once you call setlocale(3C) and
>> localeconv(3C), the Standard C Library doesn't release its own locale
>> handles until process termination. So you might think you save a lot
>> of memory by destroying and constructing the same locales. You're
>> really not. It's the Standard C Library locale data which takes up a
>> lot of space.
> You have a working knowledge of all Standard C Library implementations?

I happen to do, yes, for the operating systems that I've been testing
on. I also happen to know that you don't. This fact alone pretty much
closes up *this* particular discussion.

Do yourself, and this mailing list a favor: either write a patch which
addresses all of your concerns *AND* eliminates all the race
conditions reported, or stop this pseudo software engineering bullshit
via email.

There is apparently, a high concentration of know-it-alls on this
mailing list, who are much better at detecting race conditions and
thread unsafety than the tools themselves. Too bad they aren't as good
at figuring out their own bugs.

It took eight months for anyone here to even *acknowledge* that
numpunct and moneypunct do have, in fact, a thread safety problem.
Never mind that the test case for these facets had been crashing for 4
years. To be quite blunt and to the point, after 8 months of denying
obvious facts, your credibility is quite a bit under question at this

This entire discussion has become a perfect illustration with what's
wrong with the ASF, as reported here:

Stefan Teleman
KDE e.V.

View raw message