On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek <travis.vi...@roguewave.com> 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 point. This entire discussion has become a perfect illustration with what's wrong with the ASF, as reported here: http://www.mikealrogers.com/posts/apache-considered-harmful.html -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
