[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iconv modules
From: |
Bruno Haible |
Subject: |
Re: iconv modules |
Date: |
Mon, 15 Jan 2007 14:52:26 +0100 |
User-agent: |
KMail/1.9.1 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: iconv modules,
Bruno Haible <=