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
