Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 08/24/2015 11:07 AM, Markus Armbruster wrote:
>
>>> You can prevent GTK+ from calling setlocale() by using
>>> gtk_disable_setlocale() before gtk_init(), but note that setlocale() is
>>> needed for gettext.
>> 
>> We can
>> 
>> (A) Internationalize our complete code base
>> 
>> (B) Run in the C locale
>> 
>>     Breaks GTK's internationalization.
>> 
>> (C) Run in a mixed locale
>> 
>>     Whenever something breaks, we switch another LC_ to the C locale.
>> 
>>     Can partially break GTK's internationalization.
>> 
>> I happily concede that (A) would be best.  Until the manpower to pull it
>> off appears, I recommend (B), because it's safer than (C), and avoids
>> inconsistent localization, such as German messages combined with
>> non-German number formatting.
>
> Is it still possible for:
>
> (D) Run in a controlled mixed locale
>    GTK runs completely in the locale determined by setlocale() (since it
> never has to display raw JSON)
>    We fix our JSON output code to use thread-specific locale
> manipulations to (temporarily) switch to C locale before printing JSON
>
> that way, GTK still shows full German formatting for any localized
> message in the GUI that happens to print numbers, but the JSON output
> (which is independent of the GUI) also behaves correctly as a C-only entity.

Switching back to C locale whenever some unwanted locale-dependency
breaks the code is problematic, because it involves finding all the
places that break, iteratively (euphemism for "we debug one breakage
after the other, adding temporary locale switches as we go).

I'd feel much better about confining GTK in its own thread, and setting
only that thread's locale.

If that's impractical, perhaps we can switch locale just around GTK
code.  Thread-locally, of course.

> I don't know how well mingw supports thread-specific locales (POSIX
> requires it, but we all know that mingw is behind the curve when it
> comes to POSIX...); BSD and glibc should be okay, though.

I have no idea.  We could have configure checking whether we have
thread-local locale, and if not, disable internationalization entirely.