stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wojciech Meyer <wojciech.me...@googlemail.com>
Subject Re: STDCXX-1056 : numpunct fix
Date Fri, 21 Sep 2012 00:04:09 GMT
Liviu Nicoara <nikkoara@hates.ms> writes:

> On Sep 20, 2012, at 5:23 PM, Stefan Teleman wrote:
>
>> On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek
>> <Travis.Vitek@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.

I fully agree - tools are great, however I know a little about
compilers, and I can tell you that there are limits of static guarantees
you can get from any analyser, because in nature there is something
defined as a "halting problem", which limits the tools even the topnotch
ones based on abstract interpretation to the certain extent.  The
halting problem says: "for every program in a formal language that is
Turing complete you can't say with 100% assurance it will halt for every
input data". You can try to analyse it statically, but then there is a
balance between analysing and interpreting parts of it, even in the
extreme case if you run it - you will not know if it suppose to
halt. Therefore please use tools but be a bit reserved for the results.

All these MT analysers are based on a simple heuristics and logical
assertions that can't give you 100% right results. I don't think people
here are picky about your patches, it's just better sometimes to take a
breath and see the big picture.

--
Wojciech Meyer
http://danmey.org

Mime
View raw message