X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW
X-Spam-Check-By:	sourceware.org
Message-ID:	<4D40E1EB.8030401@cwilson.fastmail.fm>
Date:	Wed, 26 Jan 2011 22:09:31 -0500
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Bug in libiconv?
References:	<20110124154158 DOT GA15279 AT calimero DOT vinschen DOT de> <4D3E3EF6 DOT 7010501 AT cwilson DOT fastmail DOT fm>
In-Reply-To:	<4D3E3EF6.7010501@cwilson.fastmail.fm>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 1/24/2011 10:09 PM, Charles Wilson wrote:
> Now, since there has not yet been an updated upstream release of
> libiconv, my first step would be to simply rebuild our existing
> libiconv-1.13.1 on a platform with current cygwin (1.7.7-1), and try the
> test case again.

Rebuilt libiconv against 20110117 snapshot.  Built test case.  Still see
erroneous behavior:

iconv: 138 <Invalid or incomplete multibyte or wide character>
in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft
= 492
iconv: 138 <Invalid or incomplete multibyte or wide character>
in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft
= 492
iconv: 138 <Invalid or incomplete multibyte or wide character>
in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft
= 492
in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 480

> If that doesn't correct the issue...then I'd try to run your test case
> on linux, but *explicitly* using libiconv on that system, rather than
> (as is typically the case on linux) relying on the underlying glibc
> implementation of iconv functionality. 

Did this.  Here are the characteristics of the test case object and
executable:

$ ldd ./foo
        linux-vdso.so.1 =>  (0x00007fff51928000)
        libiconv.so.2 => /home/me/libiconv/_inst/lib/libiconv.so.2
(0x00007f0b7d7dd000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003d5b400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003d5b000000)

$ nm foo.o | grep ' U '
                 U __errno_location
                 U exit
                 U fprintf
         >>      U iconv
         >>      U iconv_close
         >>      U iconv_open
                 U printf
                 U setlocale
                 U stderr
                 U strerror
                 U strlen

It works fine:

in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960

> If the test case fails there,
> then we've got a presumption that the problem is in the (generic,
> cross-platform bits of) libiconv library itself. 

Well, apparently the problem is not the generic, cross-platform bits of
libiconv.  It's in the cygwin-specific bits, and/or how it interfaces
with cygwin's underlying charset manips.  So...

> Then, it's debugging
> time... :-(

...it's still debugging time.  Sigh.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -