Archived issue #0022808
Undocumented change of global locale
Description
Post from the forum - http://www.opencascade.org/org/forum/thread_22210/.
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."
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."
Public activity
6 archived notes
Participants are labeled by their role within this record.
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 Attachment 1 (PATCH)
Attachment 2 (PATCH) supersedes Attachment 1 (PATCH), it also removes #include <locale.h>
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 Commenter 2, or switching global setting, like _configthreadlocale() in MSVC)
- 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 Commenter 2, or switching global setting, like _configthreadlocale() in MSVC)
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.
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.
The problem has been corrected by fix for 0022898 issue.
Related records