I was building glib in my Windows environment (win10 + vs19, vs17) and started to investigate the test failures. One of the failing tests was “glib:glib / unicode-caseconv”.
It failed for the tests which involve setting the locale to a special locale tr_TR or lt_LT. Using the debugger I could figure out that the reason for this was that it did use “setlocale” for modifing the locale but the functions g_utf8_strup(…) and g_utf8_strdown(…) are using - via get_locale_type() - and only in case of G_OS_WIN32 the g_win32_getlocale() function for adopting their behaviour to the current locale. In my environment the result of this functions wasn´t at all affected by the setlocale(…) calls - in my case the result was based on decoding the ThreadLocale (and not returning some environment variable).
With all this said I see two curiosities (at least for me) which I wanted to share with whoever might be interested:
- The implementation of “g_win32_getlocale()” function doesn´t look as it is intended to be used as a replacement for setlocale(*, NULL) - even if the name and the documentation might suggest this
- This exact test doesn´t fail in your gitlab-ci environment and I don´t have a clue why