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.
>> +#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
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)