bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] c-strtod.c patch for non-glibc mixed-locale encodings


From: Bruno Haible
Subject: Re: [Bug-gnulib] c-strtod.c patch for non-glibc mixed-locale encodings
Date: Thu, 9 Sep 2004 13:25:07 +0200
User-agent: KMail/1.5

Paul Eggert wrote:
> On second thought, since the standard only says that strtod inspects
> LC_NUMERIC (and not any other locale category), one could argue that
> even if LC_NUMERIC is incompatible with LC_CTYPE, strtod is still
> supposed to work.

Yes, that's how I see it too:

- Mixed locales are best handled by avoiding LC_ALL and manipulating the
  locale facets that one needs. In the case of strtod this is probably
  LC_NUMERIC and LC_CTYPE. In the case of regexps it is LC_COLLATE and
  LC_CTYPE. Etc.

- By setting just the LC_NUMERIC facet to "C", you rely on the fact that
  the functions operate correctly even when a mixed locale is active
  (for example, when LC_CTYPE=de_DE and LC_NUMERIC=C). You can assume that
  it works, because POSIX specifies that it should work this way.

- When there are incompatible facets, such as LC_CTYPE=de_DE.UTF-8 and
  LC_NUMERIC=de_DE.ISO-8859-1, glibc uses the "C" locale instead; other
  implementations probably don't do this. However, in this case you want
  to set a facet to "C", and "C" is compatible to everything else.

So there is no problem with the classic approach:

     saved_locale = setlocale (LC_NUMERIC, NULL);
     if (saved_locale)
       saved_locale = strdup (saved_locale);
     ......
     setlocale (LC_NUMERIC, "C");
     ......
     if (saved_locale)
       setlocale (LC_NUMERIC, saved_locale);

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]