Re: iconv modules

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Let us know when we can remove the iconvme module. Remember the migration
> path:
>   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 only use of the modules are in
striconv.c:

  if (c_strcasecmp (from_codeset, to_codeset) == 0)
    return strdup (src);
  else
    {
#if HAVE_ICONV
      iconv_t cd;
      char *result;

      /* Avoid glibc-2.1 bug with EUC-KR.  */
# if (__GLIBC__ - 0 == 2 && __GLIBC_MINOR__ - 0 <= 1) && !defined 
_LIBICONV_VERSION
      if (c_strcasecmp (from_codeset, "EUC-KR") == 0
          || c_strcasecmp (to_codeset, "EUC-KR") == 0)
        {
          errno = EINVAL;
          return NULL;
        }
# endif

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

(Btw, some more information, in the comment, on what the glibc-2.1 bug
implies would be useful.  Or an URL to a bug report or something.)

I'm hesitating to move from iconvme to striconv because of these
additional dependencies; increasing the footprint of libidn without
any (as far as I can see) improvement seems like a bad move.

/Simon