Hi Kirill, > This is some interesting information. In the recent months I was working on > windows-specific implementation of POSIX newlocale/uselocale functions as > well as replacements for locale-related CRT functions.
When you do that, please use Gnulib's test suite, to make sure that patches you submit to mingw-w64 are of high quality. Too often I've made the experience that when a C runtime library adds a new feature, it's buggy in the first release and it needs another release to stabilize — and so I need to add yet another workaround to Gnulib, for yet another silly bug. All that because programmers did not properly test the code that they submitted. > I have collected some information about locale-related features in Windows > API and CRT. I have posted it to mingw-w64 list and you can find it here if > you're interested[1]. > [1] https://sourceforge.net/p/mingw-w64/mailman/message/59198335/ It's a good summary. However, I disagree with this: > msvcr80.dll introduced support for thread locales with _configthreadlocale[6] > function. > Makes implementing POSIX uselocale(3) easier :). I don't think it makes implementing uselocale() easier. With _configthreadlocale, the programmer has the choice between two models: - All threads have the same locale, - Or: Each threads has its own locale. Whereas with POSIX uselocale, a certain number of threads can have their own locale each, and the other threads all have the same locale. Also, note that it takes several Windows '_locale_t' objects, to represent a single POSIX 'locale_t' object. > For example, are you aware that CRTs starting with msvcr80.dll (in particular > UCRT) natively support thread locales? I was wondering if libintl/libiconv > take this into account, because if not, this may lead to unexpected surprises. GNU software cannot support _all_ of the possible operation modes possible on Windows. It's intended to support the default operation modes, and non-default ones only when there is a high necessity (such as _setmode). Bruno
