This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug in libiconv?
On Jan 26 08:43, Charles Wilson wrote:
> On 1/26/2011 8:26 AM, Corinna Vinschen wrote:
> > On Jan 26 13:15, firstname.lastname@example.org wrote:
> >>> Here's what happens on Cygwin:
> >>> - Even though the last parameter to iconv is defined in bytes, the
> >>> value of outbytesleft after the conversion is the number of remaining
> >>> wchar"t's, not the number of remaining bytes. That's contrary to
> >>> what POSIX defines, see
> >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
> >> IMHO, the count is correct.
> >> On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes.
> >> So the buffer is 512 bytes.
> >> In the first 3 cases, 10 input bytes were consumed so that there remains
> >> in the buffer (512 - 20) = 492 bytes.
> >> In the last case all 16 bytes are consumed so there remains in
> >> the buffer (512 - 32) = 480 bytes.
> > Yes, you're right. Quite obviously I misinterpreted the results without
> > realizing that the buffer is smaller under Cygwin.
> Sure, but there ARE still bugs in libiconv on Cygwin -- specifically:
> - Even though iconv_open has been opened explicitely with "UTF-8" as
> input string, the conversion still depends on the current application
> codeset. That doesn't make sense.
> - 'iconv_close ((iconv_t) -1);' crashes the application with a SEGV.
Indeed. But it was an important hint, nevertheless. It just didn't
occur to me that the buffer size is different between Cygwin and
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple