Re: Use of bind_textdomain_codeset()

[Bruno Haible <haible@xxxxxxx>]

Byrial Jensen writes:

> I have found that all localized messages from fetchmail(1) is
> converted to ASCII when running Redhat Linux 7.0 which uses
> glibc 2.1.92. 
> 
> I intend to propose a patch to the author to solve problem, but
> I would first like to hear here if it does it the right way. The
> important part of the patch is:
> 
> @@ -160,6 +170,19 @@ int main(int argc, char **argv)
>  #ifdef ENABLE_NLS
>      bindtextdomain(PACKAGE, LOCALEDIR);
>      textdomain(PACKAGE);
> +#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
> +   /*
> +    * GNU libc 2.2 will convert all translated messages from gettext()
> +    * to what it thinks is the current output character set. The default
> +    * depends on the LC_CTYPE locale, but we cannot permanently set this
> +    * as it would affect all isXXXXX() calls all over the program --
> +    * so we have to bind the default charset to the right value instead.
> +    */
> +    setlocale (LC_CTYPE, "");
> +    bind_textdomain_codeset (PACKAGE, nl_langinfo(CODESET));
> +    bind_textdomain_codeset ("libc", nl_langinfo(CODESET));
> +    setlocale (LC_CTYPE, "C");
> +#endif
>  #endif

This will nearly work. But not completely, because glibc's gettext function
needs the LC_CTYPE locale for the codeset _and_ for the transliteration.
You are only setting the codeset.

Moreover, nl_langinfo is not completely portable. bind_textdomain_codeset
will also be contained in the next standalone gettext package, thus
HAVE_BIND_TEXTDOMAIN_CODESET will be true even on old platforms with gettext,
and your code won't compile.

I would therefore favour the opposite approach: Simply use

      setlocale (LC_CTYPE, "");

and simulate the isXXXXX() calls with substitutes specific to the C locale.
Take for example the files [1] and [2], specially optimized for the C locale.

> And one more question: On Redhat 7.0 bind_textdomain_codeset is
> only in libc.a but not libc.so, so I have to statically link to
> use the function. Is this a specific Redhat bug, or a bug in
> glibc 2.1.92?

It was a bug in glibc 2.1.92 and is fixed in 2.1.95. Thanks for
reporting it, anyway. You have to expect things like this if you buy a
distribution based on a snapshot C library and a snapshot C/C++
compiler.

Bruno

[1] ftp://ftp.ilog.fr/pub/Users/haible/gnu/c-ctype.h
[2] ftp://ftp.ilog.fr/pub/Users/haible/gnu/c-ctype.c
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/