Your message dated Sat, 01 May 2004 10:31:06 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#179115: libc6: iconv_open doesn't handle "char"
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 31 Jan 2003 00:04:04 +0000
>From [EMAIL PROTECTED] Thu Jan 30 18:04:03 2003
Return-path: <[EMAIL PROTECTED]>
Received: from pool-68-162-146-35.pitt.east.verizon.net (debian) [68.162.146.35] (mail)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18eOf5-0005NW-00; Thu, 30 Jan 2003 18:04:03 -0600
Received: from jdorje by debian with local (Exim 3.36 #1 (Debian))
id 18eOfA-0003O2-00; Thu, 30 Jan 2003 19:04:08 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Jason Dorje Short <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: libc6: iconv_open doesn't handle "char"
X-Mailer: reportbug 2.10
Date: Thu, 30 Jan 2003 19:04:08 -0500
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=0.6 required=5.0
tests=SPAM_PHRASE_00_01
version=2.41
X-Spam-Level:
Package: libc6
Version: 2.3.1-10
Severity: normal
Tags: sid
In GNU iconv, "" as a character encoding is an alias for "char".
In fact on many systems it seems "char" is the local 8-bit encoding
while "" means nothing.
But glibc iconv works for "", but fails on "char". This is unfortunate.
I haven't tried out "wchar", but I believe it is supposed to be the
"local" 16-bit encoding.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian 2.4.19-ck10 #1 Thu Oct 24 05:34:48 EST 2002 i686
Locale: LANG=en_US.ISO-8859-1, LC_CTYPE=en_US.ISO-8859-1 (ignored: LC_ALL set)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl
-- no debconf information
---------------------------------------
Received: (at 179115-done) by bugs.debian.org; 1 May 2004 01:31:07 +0000
>From [EMAIL PROTECTED] Fri Apr 30 18:31:07 2004
Return-path: <[EMAIL PROTECTED]>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BJjLP-00077z-00; Fri, 30 Apr 2004 18:31:07 -0700
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id 3E7ABDF4FF; Sat, 1 May 2004 10:31:06 +0900 (JST)
Date: Sat, 01 May 2004 10:31:06 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: Jason Dorje Short <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: Bug#179115: libc6: iconv_open doesn't handle "char"
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
X-CrossAssassin-Score: 1
At Thu, 30 Jan 2003 19:04:08 -0500,
Jason Dorje Short wrote:
> In GNU iconv, "" as a character encoding is an alias for "char".
You didn't mention whether it's iconv(1) problem or iconv(3). I
assume it's iconv(1).
> In fact on many systems it seems "char" is the local 8-bit encoding
> while "" means nothing.
>
> But glibc iconv works for "", but fails on "char". This is unfortunate.
>
> I haven't tried out "wchar", but I believe it is supposed to be the
> "local" 16-bit encoding.
You misunderstand the behavior of designating "" or // for iconv(1) -f
or -t. Look at __gconv_open in glibc. Its behavior is to use the
current locale character encodings.
There is no valid locale name "char" for iconv(1); make sure to use
iconv -l.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
