Re: [bug-gnu-libiconv] Solaris libiconv vs. GNU libiconv in terms of 646

[Bruno Haible]

Hello,

Dagobert Michelsen wrote:
> I am currently packaging zsh for Solaris when I noticed
> some failing tests due to problems with libiconv.
> It looks like Solaris uses 646 as standard which is
> known to Solaris libiconv but not GNU libiconv.

Yes, this is a known problem. Solaris uses "646" to denote the ASCII
encoding, and GNU libiconv does not.

What is standard in the realm of character encodings, is defined by IANA,
here:
  http://www.iana.org/assignments/character-sets

> I already found this in the notes:
> 
>    Q: Support encodings mentioned in RFC 1345 ?
>    A: No, they are not in use any more. Supporting ISO-646 variants  
> is pointless
>       since ISO-8859-* have been adopted.

The issue is actually slightly different. The encoding itself is well
supported by both Solaris iconv and GNU libiconv. Only the name used
by Solaris is a fantasy name.

> The troubles from the zsh-people is best described at
>     <http://www.zsh.org/mla/workers/2008/msg00271.html>
> The ZSH-people are currently building a workaround, but
> this whole situation should be better addresses in libiconv.

This situation has been addressed in full generality - there is not only
Solaris and "646", there is also HP-UX and "hp15CN", and many others -
in the gnulib module 'iconv_open', here:

   http://www.gnu.org/software/gnulib/MODULES.html#module%3Diconv_open

Regarding the workaround that you are doing:

  - The idea to use "US-ASCII" for GNU libiconv but "646" for Solaris iconv
    is right.

  - Instead of a configure-time test you can also use a simpler compile-time
    test:

      #ifdef _LIBICONV_VERSION
        /* using GNU libiconv */
      #else
        /* using the native system iconv */
        #ifdef __sun
          /* using the Solaris iconv */
        #else
          /* other systems */
        #endif
      #endif

  - Regarding the recommendation to use Solaris iconv, I recommend the
    opposite: Solaris iconv is known to crash in some situations.

> Additionally, the "646-problem" on Solaris with libiconv
> seems to be widely seen, e. g. here:
>    <http://www.blastwave.org/mantis/view_bug_advanced_page.php? 
> f_id=0001849>

This URL does not work for me. It shows a login screen, allowing an
anonymous login. After this, no way to search a bug by number.

Bruno

PS: This mail should appear as
<http://lists.gnu.org/archive/html/bug-gnu-libiconv/2008-02/msg00003.html>