-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libinstpatch is hijacking the application's locale #37
Comments
Also, with that being said, doesn't setlocale(LC_NUMERIC, "C"); (Even though this still hijacks the |
Example random breakage: realnc/dosbox-core#7 |
I understand what you said in previous message. However for the reason explained in #26 , for now, I don't see another solution that calling |
Well, I'm not calling that myself. Fluidsynth does. Also, it's not thread safe. If another thread in the application calls one of the many function that depend on current locale, you get race conditions. You can't do anything about it. |
Not really, actually, fluidsynth library doesn't depend of the locale. But the application that use |
I must admit that I underestimated the scope of this libinstpatch/libinstpatch/IpatchXmlObject.c Line 852 in 8c56777
I never had to deal with InvariantCulture file parsing in C before. So, the best solution I currently can come up with is: char const *oldLocale = setlocale(LC_ALL, 0);
setlocale(LC_ALL, "C");
// read xmlfile
setlocale(LC_ALL, oldlocale); But as already mentioned by @realnc, this is broken due to the missing thread-safety. One might look into glib, whether it provides some useful "sscanf()-locale-aware" alternative. Or we need to revert b45b2db and find an alternative way to support WinXP. |
On POSIX you can use uselocale which exists to solve this exact issue. On Windows there's _configthreadlocale |
Aha, ok. So, in order to be absolutely bullet proof, we would need to do something like below, I'd guess: #ifdef WIN32
char* oldLocale = setlocale(LC_NUMERIC, NULL);
int oldSetting = _configthreadlocale(0);
_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
setlocale(LC_NUMERIC, "C");
#else
locale_t oldLocale = uselocale((locale_t) 0);
locale_t newLocale = newlocale(LC_NUMERIC_MASK, "C", (locale_t) 0);
uselocale(newLocale);
#endif
// read xmlfile
#ifdef WIN32
setlocale(oldLocale)
_configthreadlocale(oldSetting);
#else
uselocale(oldLocale);
freelocale(newLocale);
#endif Is that common practice? I've never seen code like that before. |
Note this commit is just a way to give binaries for those that don't want to build from source.
Yes, I remember I was facing to sscanf that depends of the locale (note that printf() could depend of locale also). |
May be, this could be simpler ?.
|
That way you would leak the newlocale handle. |
Oups, yes! |
libinstpatch/misc.c
has this code in it:This effectively hijacks the locale handling of the application that uses libinstpatch. I believe it's a bad idea to call
setlocale()
in a library and it's pretty much impossible to fix this from the application side becausesetlocale()
is not thread safe.(In my case, I don't use libinstpatch directly, but I do use libfluidsynth, which in turn uses libinstpatch.)
The text was updated successfully, but these errors were encountered: