Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of wojciech.meyer@googlemail.com
 designates 74.125.82.182 as permitted sender)
From: Wojciech Meyer <wojciech.meyer@googlemail.com>
To: dev@stdcxx.apache.org
Subject: Re: [jira] [Closed] (STDCXX-1056) std::moneypunct and std::numpunct
 implementations are not thread-safe
References: <328177502.125959.1348617367665.JavaMail.jiratomcat@arcas>
	<506246D5.10602@hates.ms>
Date: Wed, 26 Sep 2012 01:08:51 +0100
In-Reply-To: <506246D5.10602@hates.ms> (Liviu Nicoara's message of "Tue, 25
	Sep 2012 20:05:41 -0400")
Message-ID: <wfehlpy7ak.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

Hi guys,

I think the consensus about this bug is that everybody wants to fix it.
Stefan has a patch but I got completely lost what is the exact reason of
not applying it. It would be a shame to stop at this point.

Liviu Nicoara <nikkoara@hates.ms> writes:

> On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
>>
>>       [ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Stefan,
>
> I don't think it's ok to close this bug. The race conditions are there
> and we have not come to a completely satisfactory conclusion on how to
> deal with them, or even if we should deal with them. Whichever it is
> we gotta keep this discussion open. I sure hope you want to be a part
> of it.
>
> FWIW, I have spent quite some time looking at your proposed patch and
> I am going to reopen the incident. If I can.
>
> Liviu
>
>>
>> Stefan Teleman closed STDCXX-1056.
>> ----------------------------------
>>
>>      Resolution: Won't Fix
>>
>> Bug will not be fixed. Upstream refuses to acknowledge the existence of the bug in spite of objective evidence to the contrary.
>>
>>> std::moneypunct and std::numpunct implementations are not thread-safe
>>> ---------------------------------------------------------------------
>>>
>>>                  Key: STDCXX-1056
>>>                  URL: https://issues.apache.org/jira/browse/STDCXX-1056
>>>              Project: C++ Standard Library
>>>           Issue Type: Bug
>>>           Components: 22. Localization
>>>     Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
>>>          Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ Compilers 12.1, 12.2, 12.3
>>> Issue is independent of platform and/or compiler.
>>>             Reporter: Stefan Teleman
>>>               Labels: thread-safety
>>>              Fix For: 4.2.x, 4.3.x, 5.0.0
>>>
>>>          Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, stdcxx-4.3.x-numpunct-perfect-forwarding.patch
>>>
>>>
>>> several member functions in std::moneypunct<> and std::numpunct<> return
>>> a std::string by value (as required by the Standard). The implication of return-by-value
>>> being that the caller "owns" the returned object.
>>> In the stdcxx implementation, the std::basic_string copy constructor uses a shared
>>> underlying buffer implementation. This shared buffer creates the first problem for
>>> these classes: although the std::string object returned by value *appears* to be owned
>>> by the caller, it is, in fact, not.
>>> In a mult-threaded environment, this underlying shared buffer can be subsequently modified by a different thread than the one who made the initial call. Furthermore, two or more different threads can access the same shared buffer at the same time, and modify it, resulting in undefined run-time behavior.
>>> The cure for this defect has two parts:
>>> 1. the member functions in question must truly return a copy by avoiding a call to the copy constructor, and using a constructor which creates a deep copy of the std::string.
>>> 2. access to these member functions must be serialized, in order to guarantee atomicity
>>> of the creation of the std::string being returned by value.
>>> Patch for 4.2.1 to follow.
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>

--
Wojciech Meyer
http://danmey.org