From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11575 invoked by alias); 26 Jan 2011 13:44:09 -0000 Received: (qmail 11561 invoked by uid 22791); 26 Jan 2011 13:44:07 -0000 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 Received: from out1.smtp.messagingengine.com (HELO out1.smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Jan 2011 13:44:02 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id EC32F206D4 for ; Wed, 26 Jan 2011 08:44:00 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 26 Jan 2011 08:44:00 -0500 Received: from [192.168.1.3] (user-0c6se63.cable.mindspring.com [24.110.56.195]) by mail.messagingengine.com (Postfix) with ESMTPSA id 99A3A406B6D; Wed, 26 Jan 2011 08:44:00 -0500 (EST) Message-ID: <4D402507.6030205@cwilson.fastmail.fm> Date: Wed, 26 Jan 2011 17:01:00 -0000 From: Charles Wilson 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@cygwin.com Subject: Re: Bug in libiconv? References: <1309.192.168.6.58.1296044105.squirrel@simlinux> <20110126132613.GN28470@calimero.vinschen.de> In-Reply-To: <20110126132613.GN28470@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-01/txt/msg00336.txt.bz2 On 1/26/2011 8:26 AM, Corinna Vinschen wrote: > On Jan 26 13:15, simrw@sim-basis.de wrote: >>> Here's what happens on Cygwin: >>> >>> $ gcc -g -o ic ic.c -liconv >>> $ ./ic >>> iconv: 138 >>> in = , inbuf = <ä sana>, inbytesleft = 7, >> outbytesleft = 492 >>> iconv: 138 >>> in = , inbuf = <ä sana>, inbytesleft = 7, >> outbytesleft = 492 >>> iconv: 138 >>> in = , inbuf = <ä sana>, inbytesleft = 7, >> outbytesleft = 492 >>> in = , inbuf = <>, inbytesleft = 0, outbytesleft = 480 >>> >>> So, AFAICS, there are two problems: >>> >>> - Even though iconv_open has been opened explicitely with "UTF-8" as >>> input string, the conversion still depends on the current application >>> codeset. That dsoesn't make sense. >>> >>> - 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. and - 'iconv_close ((iconv_t) -1);' crashes the application with a SEGV. -- 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