qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code
Date: Mon, 24 Aug 2015 11:18:20 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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.

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]