Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Nov 2012 09:02:03 -0500
From: Rich Felker <>
Subject: Re: Re: Revisiting 1.0 wishlist

On Tue, Nov 20, 2012 at 01:40:01PM +0000, Roy wrote:
> Rich Felker <dalias <at>> writes:
> > support for a to-be-determined set of additional
> > legacy character encodings in iconv. At the very
> > least, the major legacy encodings for Korean and
> > Traditional Chinese should be included, and it 
> > may also be desirable to add support for stateful
> > encodings (ISO-2022). Aside from these, I believe
> > all encodings important for supporting legacy data
> > on the web, in email, etc. are supported.
> Does it include EBCDIC, especially the stateful(SI-SO)
>  Double-Byte Character Set(DBCS) EBCDICs?
> The glibc gconv module support DBCS EBCDIC which GNU
>  libiconv does not support.
> (I asked libiconv devs and they told me they do 
> not have intention to support them).

At present, musl's iconv does not support any stateful encodings (the
iconv_t it not actually a pointer to any state; it's just a bitfield
storing the source and dest encodings directly), nor does it support
EBCDIC at all. In general I believe stateful encodings may be relevant
(ISO-2022-JP used to be the main Japanese encoding used on IRC; is
that still true?) but I'm unsure whether even EBCDIC itself (much less
derived DBCS's) has modern relevance with respect to iconv. I think
the important question to ask is: "Is there any chance of an
application which uses iconv to support receiving data in varied
character encodings receiving data as EBCDIC?" My guess is no, but if
you know usage cases I'll listen.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.