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

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

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.

>> 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:


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:

code using thread-safe locale swapping to our once-init C locale_t
code using strstr of the localeconv()->decimal_point

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

Attachment: signature.asc
Description: OpenPGP digital signature

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