MantisBT - Community
View Issue Details
0022808Community[OCCT] OCCT:Foundation Classespublic2011-11-21 11:122013-04-29 15:22
[OCCT] 6.5.2 
[OCCT] 6.6.0[OCCT] 6.6.0 
0022808: Undocumented change of global locale
Post from the forum - [^]
1."What is the purpose of the line 1549
(void)setlocale(LC_ALL, "");
in Storage_Schema.cxx, Storage_Schema::ICreationDate()?
And more important why is the locale not set back, like LC_NUMERIC in the same function? This function gets called everytime I use the OCC save mechanism. This (for me) unrecognized change of the localization messed things up in the rest of my application.

As a fix I used the OSD_Localizer to encapsulate my OCC calls and prevent interference with my own localization settings.
But I think this should still be considered a bug."

2. "
Markus Rhein | reply 2011/11/18 15:49
I don╢t think OSD_Localizer is working as intended.
Is it possible that the variable myLocale can get corrupt before restore () gets called?

Also I would suggest restoring the original localization settings in the destructor of OSD_Localizer."
No tags attached.
related to 0022898closed abv IGES import fails in german environment 
related to 0022933closed bugmaster Thread-safe locale handling in OSD_Localizer 
patch drop-setlocale.patch (2,150) 2012-01-17 18:21
patch drop-setlocale2.patch (2,423) 2012-01-17 18:44
Issue History
2011-11-21 11:12szyNew Issue
2011-11-21 11:12szyAssigned To => abv
2012-01-17 16:26abvRelationship addedrelated to 0022898
2012-01-17 18:20barbierNote Added: 0019157
2012-01-17 18:21barbierFile Added: drop-setlocale.patch
2012-01-17 18:22barbierNote Edited: 0019157bug_revision_view_page.php?bugnote_id=19157#r3033
2012-01-17 18:44barbierFile Added: drop-setlocale2.patch
2012-01-17 18:45barbierNote Added: 0019160
2012-01-20 18:31abvNote Added: 0019213
2012-01-20 18:31abvStatusnew => assigned
2012-01-20 18:47barbierNote Added: 0019214
2012-01-30 08:17abvRelationship addedrelated to 0022933
2012-03-22 06:16abvTarget Version6.5.3 => 6.5.4
2012-10-23 19:01abvTarget Version6.5.4 => 6.6.0
2013-02-19 12:41kgvNote Added: 0023384
2013-02-19 12:41kgvStatusassigned => feedback
2013-02-19 12:41kgvAssigned Toabv => bugmaster
2013-02-19 18:46bugmasterStatusfeedback => tested
2013-02-19 18:47bugmasterNote Added: 0023391
2013-02-19 18:47bugmasterStatustested => verified
2013-02-19 18:47bugmasterResolutionopen => fixed
2013-04-23 13:36aivStatusverified => closed
2013-04-29 15:22aivFixed in Version => 6.6.0

2012-01-17 18:20   
(edited on: 2012-01-17 18:22)
Since dates are created by calling strftime with a locale-independent format, result is independent of user's locale and all calls to setlocale can be dropped (from src/Storage/Storage_Schema.cxx and src/XmlLDrivers/XmlLDrivers.cxx). See drop-setlocale.patch

2012-01-17 18:45   
drop-setlocale2.patch supersedes drop-setlocale.patch, it also removes #include <locale.h>
2012-01-20 18:31   
We shall use OSD_Localizer class to set / unset locales throughout the OCCT code. As indicated in discussions on the forums, this class needs to be improved:

- Make copy of the string returned by setlocale
- Restore locale in destructor (perhaps optionally)
- Provide thread-safe work with locales (e.g. using C++ locales as suggested by Denis Barbier, or switching global setting, like _configthreadlocale() in MSVC)
2012-01-20 18:47   
My reluctance against setlocale() is that this function modifies locales for *all* threads. This may be a serious problem in a multithreaded environment, even if original locale is restored afterwards, because OCC code may cause trouble in 3rd party code.

This is why I advocated for using C++ locales, one can change locale for a single stream. OTOH it seems that uselocale() is a new POSIX 2008 function which works like setlocale() but only on the current thread. This may be an option, I have no idea how well it is supported. It is in glibc for a long time. You already provided a similar solution on Windows.
2013-02-19 12:41   
Dear bugmaster,

this issue was taken into account within 0022898 patch.
Please close this bug.
2013-02-19 18:47   
The problem has been corrected by fix for 0022898 issue.