Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of wojciech.meyer@googlemail.com
 designates 209.85.212.176 as permitted sender)
From: Wojciech Meyer <wojciech.meyer@googlemail.com>
To: dev@stdcxx.apache.org
Subject: Re: STDCXX-1056 : numpunct fix
References: 
 <CALdE9OD1q8y6yo7FhZLwdSA0w5R1Jy0gTFY39GjGbgT+cHYhOQ@mail.gmail.com>
	<505A6877.7090507@hates.ms>
	<CALdE9ODV=msOJgWiOVRcTDe1F=sfFQpnMXaZpoexG5QP3mg5+Q@mail.gmail.com>
	<346B7FD6-C961-4C0C-91C3-9FBBE442490D@hates.ms>
	<CALdE9OAChzdRQLuh=XR-cTOAr+gix-uEpvZugFFjDe8JiCXkWQ@mail.gmail.com>
	<53D52D02E87FA04A948D9A74A7AE617C12E89935C4@Eagle.Blue.Roguewave.Com>
	<CALdE9ODPoaUbK8eXFEcQ9dZGn=ogUz2-xc2Gz-10y1=8Bkz-sw@mail.gmail.com>
	<F3BDBB4A-B053-4A75-AE5F-D7E32C260E8F@hates.ms>
Date: Fri, 21 Sep 2012 01:04:09 +0100
In-Reply-To: <F3BDBB4A-B053-4A75-AE5F-D7E32C260E8F@hates.ms> (Liviu Nicoara's
	message of "Thu, 20 Sep 2012 19:46:50 -0400")
Message-ID: <wfhaqsqm12.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

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