[libvirt] [PATCH] json: fix interface locale dependency

[Martin Kletzander]

On 08/06/2012 02:52 PM, Eric Blake wrote:
> On 08/06/2012 06:24 AM, Daniel P. Berrange wrote:
>> On Mon, Aug 06, 2012 at 10:12:17AM +0200, Martin Kletzander wrote:
>>> libvirt creates invalid commands if wrong locale is selected.  For
>>> example with locale that uses comma as a decimal point, JSON commands
>>> created with decimal numbers are invalid because comma separates the
>>> entries in JSON.
>>>
>>> But even when decimal point is affected, grouping is not, because for
>>> grouping to be enabled with *printf, there has to be a apostrophe flag
>>> specified (and supported).
>>> ---
>>> Fortunately, there should be no other place where output-formatting is
>>> affected by this problem.
>>>
>>> I tried to change this in various ways with this posted one being the
>>> cleanest from my point of view, because:
>>>  - setting locale is per-proccess, not per-thread (not thread-safe)
>>
>> Actually in glibc there is a per-thread locale:
> 
> I agree that we should be using uselocale() where appropriate, rather
> than hacking with localeconv()->decimal_point.  Also, we need to make
> sure that whatever solution we come up with compiles on mingw (I'm
> afraid that localeconv()->decimal_point is not portable enough, yet).
> 

If you mean the construct then yes, this could be written better, my
fault. If you mean the use of localeconv itself it should be more
portable than nl_langinfo which was my second option.

Also when I was looking at the per-thread locale, I've found a comment
few lines up the code before all the per-thread locale functions:

Attention: all these functions are *not* standardized in any form. This
is a proof-of-concept implementation.

>>
>> GLib has a g_ascii_dtostr() which forces uses of '.' as separator. Since
>> GLib is LGPLv2+ licensed, we can just copy their impl, which actually
>> uses GLibc's uselocale() if possible, otherwise has a fallback impl.
> 
> gnulib also has a module 'ftoastr' for printing an unambiguous
> representation of floating point (one problem with the default precision
> of %lf and friends is that it rounds, so more than one floating point
> value will result in the same ambiguous output string), but alas that
> module is GPL at the moment, and I'm not sure whether it has a way to
> force the decimal point issue.
> 

I was going through the code of both of these and thanks ftoastr is
under GPL, because I didn't quite understand it. Looking at the
g_ascii_dtostr I've found that what is being done there and it amused me
a bit. After couple of checks, conditions and whatnot, it get's the
current decimal_point string from the localeconv() and replaces it with
a '.', long story short, the only difference is that instead of
strcpy(), there is memmove() used.

Not that I don't want to change the code, this is only some info I've
found and I don't know whether to change the code and if, then to what
to change it.

Martin