Re: [PATCH v2] json: fix interface locale dependency

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

 



On 08/10/2012 05:39 PM, Eric Blake wrote:
> On 08/10/2012 03:43 AM, Martin Kletzander wrote:
>>> I'm still worried about whether 'struct lconv' will compile on mingw.
>>> Then again, any system that lacks localeconf() probably also lacks any
>>> locale that would use ',' for the decimal separator, so maybe
>>> appropriate ifdef protection is all we need.
>>>
>>
>> As we based it on glib code, I'd say: "they have it like this" :)
> 
> But part of the code depends on the configure time checks that were
> performed, and glib uses different configure checks than libvirt's use
> of gnulib.  While copying the code is easy, tweaking the configure
> script to pick up the right conditions is where all the porting fun
> comes when porting a glib function to live in isolation.
> 
>>>> +#if HAVE_XLOCALE_H
>>>
>>> And where does HAVE_XLOCALE_H get defined?  Autoconf conventions say it
>>> would map to <xlocale.h> existing, but that is a non-standard header
>>> name.  Not to mention that we really care about whether newlocale and
>>> setlocale exist.
>>>
>>
>> I tried to create a have_xlocale with AC_COMPILE_IFELSE but since
>> uselocale, newlocale and freelocale are part of libc, I haven't managed
>> to make it fail.
> 
> Here's how I'd do it.  In configure.ac, add:
> 
> AC_CHECK_FUNCS_ONCE([newlocale])
> 
> if newlocale exits, then so do uselocale and freelocale; if newlocale
> does not exist, then we go to fallback code.
> 
> In bootstrap.conf, add localeconv to gnulib_modules.  Then gnulib's
> localeconv is guaranteed to exist, and we are guaranteed that our
> fallback code will compile even on mingw.
> 
> In util.c, write your code to do:
> 
> #if HAVE_NEWLOCALE
> code using thread-safe locale swapping to our once-init C locale_t
> #else
> code using strstr of the localeconv()->decimal_point
> #endif
> 

I partially had that when I read this mail. I finished it now, but to be
honest, even though it works, it's reusable and so on it doesn't look
very good. I think I'll cook one more version of that  and will post
both of them. And if you'd be so kind and had a look once more at that,
I'd appreciate that.

Martin

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]