Subject: Re: more iconv trouble
From: Vlad Harchev (hvv@hippo.ru)
Date: Fri Nov 10 2000 - 02:07:06 CST
On Thu, 9 Nov 2000, Mike Nordell wrote:
Hi,
> While trying to sort out the 8859-15/1 trouble, I simply changed the string
> in iconv to read "8859-1". The led to a crash (segv) in
> wvConvertUnicodeToiso8859_15 since neither inbytesleft nor outbytesleft
> contained legal values. It got called from try_UToC() in
> xap_EncodingManager.cpp(244) like
> iconv(iconv_handle,NULL,NULL,NULL,NULL);
Such usage means "reset conversion state" (i.e. reset shift state). Any iconv
implementation should support it.
Probably conv_handle was ((iconv_t)-1) - that's why it could crash.
Libiconv is stupid in this respect - it crashes if ((iconv_t)-1) is used as
parameter to iconv_close (and as it turns out, iconv).
Please double check that iconv implementation doesn't come from expat - it
has a very cutdown version of iconv that knows very little.
It's definitely not compiled on unix. Dunno for win32.
> Well, that explains that crash. :-)
>
> Now, is zero pointers legal input values to the function iconv()? If they
> are, shouldn't its "child" functions check what data they try to operate on?
> If a zero pointer is indeed illegal, shouldn't the function iconv() assert
> the parameters validness?
>
> /Mike (oh, forgot in my last post, please don't cc)
>
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Fri Nov 10 2000 - 02:37:40 CST