Re: iconv modules

[Bruno Haible]

Simon Josefsson wrote on 2006-12-28:
> >   iconvme::iconv_string -> str_iconv
> >   iconvme::iconv_alloc -> str_cd_iconv (with reversed arguments)
> 
> I looked into this now, for libidn, and it seems the move to striconv
> will add some additional dependencies: striconv depends on
> c-strcasecmp which depends on c-ctype which depends on stdbool.  The
> ironic part is that the reason for these dependencies is to optimize
> and work around bugs in striconv.

The main use of c_strcasecmp here is to test whether the conversion is a
no-op. This is just an optimization, so that "ascii" and "ASCII" are
considered the same quickly. You can use
  --avoid=c-strcasecmp
and
  #define c_strcasecmp strcmp
then the code will really call iconv_open in such a case.

The other use is for defending against a glibc-2.1 bug. These are so old
systems that it's not worth worrying about.

> What is the problem of using strcasecmp, or even strcmp which
> iconvme.c uses today, here?

strcasecmp (the internationalized one, not the glibc one) considers
"ascii" and "ASCII" to not be the same in a Turkish locale. strcmp does
not consider them to be the same in any locale. This partially disables
the no-op conversion optimization.

> (Btw, some more information, in the comment, on what the glibc-2.1 bug
> implies would be useful.

The EUC-KR implementation in glibc-2.1 was buggy in both directions. It
easily led to crashes.

Bruno