stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: svn commit: r644364 - in /stdcxx/trunk: src/locale_global.cpp tests/localization/
Date Thu, 03 Apr 2008 16:43:34 GMT

>-----Original Message-----
>From: Martin Sebor [] 
>Sent: Thursday, April 03, 2008 8:55 AM
>Subject: Re: svn commit: r644364 - in /stdcxx/trunk: 
>src/locale_global.cpp tests/localization/
> wrote:
>> Author: elemings
>> Date: Thu Apr  3 08:32:56 2008
>> New Revision: 644364
>> URL:
>> Log:
>> 2008-04-03  Eric Lemings  <>
>> 	STDCXX-811
>> 	* src/locale_global.cpp (std::locale::global): Replace call to
>> 	non-reentrant setlocale() C function with reentrant
>> 	__rw_setlocale object.
>I don't think that's correct. The object's dtor restores
>the original locale. We need a mutex around the call to
>setlocale. Look for/at the _RWSTD_STATIC_GUARD() and

Right. It seems that for this to be mt-safe with respect to other
library code that calls setlocale(), we would need to lock the same lock
that is used by _RW::__rw_setlocale. If don't use the same lock it would
be possible for the std::locale::global() call to change the locale
while some other library code is reading locale specific data under
protection of an active _RW::__rw_setlocale instance.

Of course the _RW::__rw_setlocale objects will always be able to call
setlocale() and mess up the state of anything expecting locale specific
behavior to work correctly. i.e. std::locale::global() is required to
call setlocale(), but the library may need to call setlocale()
internally [through a _RW::__rw_setlocale instance]. When this happens,
the global locale state [the C/C++ locale set by the setlocale()
function] will be temporarily overridden behind the users back, possibly
resulting in some interesting behavior.


View raw message