Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506

Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506

[Ludovic Courtès]

Hi Mike,

"Michael Gran" <spk121@yahoo.com> writes:

> commit aafb5062b834dc468fa2acdec7eda12e389c5bca
> Author: Michael Gran <spk121@yahoo.com>
> Date:   Thu Sep 24 08:07:38 2009 -0700
>
>     Language-specific case-conversion doesn't honor locale
>     
>     Libunistring uses a function uc_locale_language to extract the
>     current language from the locale information.  It does this by calling
>     setlocale.  This makes incompatible with Guile functions that use the
>     locale_t thread-specific locale API, because the values returned by the
>     call to setlocale ignore the locale set by uselocale.
>     
>     As a workaround, this patch extracts the language from the locale_t
>     structure's __names field.

Unfortunately this is not an option because it’s way too fragile, and
will not compile non-GNU systems that implement this API (such as
Darwin, and any POSIX 2008 system).

How about reporting a bug against libunistring so that it uses
uselocale(3) instead of setlocale(3) to determine the current language
when uselocale(3) is available?

Furthermore, we could suggest that support for the ‘locale_t’ API would
be great.  :-)

Thanks,
Ludo’.

Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506

[Mike Gran]

On Thu, 2009-09-24 at 17:29 +0200, Ludovic Courtès wrote:
> Hi Mike,
> 
> "Michael Gran" <spk121@yahoo.com> writes:
> >     Language-specific case-conversion doesn't honor locale
> >     
> >     Libunistring uses a function uc_locale_language to extract the
> >     current language from the locale information.  It does this by calling
> >     setlocale.  This makes incompatible with Guile functions that use the
> >     locale_t thread-specific locale API, because the values returned by the
> >     call to setlocale ignore the locale set by uselocale.
> >     
> >     As a workaround, this patch extracts the language from the locale_t
> >     structure's __names field.
> 
> Unfortunately this is not an option because it’s way too fragile, and
> will not compile non-GNU systems that implement this API (such as
> Darwin, and any POSIX 2008 system).

Yeah.  I know it is a poor solution.  I just wanted to throw something
out there to explain the problem.  

> 
> How about reporting a bug against libunistring so that it uses
> uselocale(3) instead of setlocale(3) to determine the current language
> when uselocale(3) is available?

I plan to.  It would be a big change, though.  

Using POSIX 2008, there is apparently no way to get from a locale_t to
the language part of the LC_CTYPE.  

Say I create a Mexican Spanish locale with makelocale(LC_CTYPE,
"es_MX.utf8")

I can then extract the 'utf8' part of the locale using
nl_langinfo_l(loc, CODESET).  But, I don't see any way to extract the
"es_MX" part of the LC_CTYPE other than by accessing the locale_t
structure directly.  Unless I'm missing something obvious.

Bruno's libunistring code relies on the ability to extract the language
of the locale (the "es" part of "es_MX.utf8"), which is easy when
calling setlocale.  So he'd have to re-write a significant bit of code
to work around it to make it work with uselocale.

> 
> Furthermore, we could suggest that support for the ‘locale_t’ API would
> be great.  :-)

Poor Bruno.

> 
> Thanks,
> Ludo’.

Thanks,

Mike

Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506

[Ludovic Courtès]

Hi,

Mike Gran <spk121@yahoo.com> writes:

> Bruno's libunistring code relies on the ability to extract the language
> of the locale (the "es" part of "es_MX.utf8"), which is easy when
> calling setlocale.  So he'd have to re-write a significant bit of code
> to work around it to make it work with uselocale.

Hmm, indeed.  Well, let’s see what Bruno can come up with.  ;-)

Thanks,
Ludo’.

Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506

[Ludovic Courtès]

Mike Gran <spk121@yahoo.com> writes:

> Yeah.  I know it is a poor solution.  I just wanted to throw something
> out there to explain the problem.  

In the meantime, we can still extend ‘scm_t_locale’ in the
‘USE_GNU_LOCALE_API’ case:

  typedef struct
  {
    locale_t   locale;
    const char language[3];
  } scm_t_locale;

Then ‘make-locale’ can somehow determine the locale name associated with
‘LC_CTYPE’; the language two-letter code can be extracted from the
locale name using the same algorithm as ‘uc_locale_language ()’, and
stored in ‘c_locale->language’.

In the ‘!USE_GNU_LOCALE_API’ there’s no problem because we already have
to acquire ‘scm_i_locale_mutex’ and setlocale(3).

I suggest that we wait for Bruno’s feedback on this and eventually take
this route (before 1.9.4!) if there’s no easy fix for libunistring.

Thanks,
Ludo’.