Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2012 00:39:03 -0400
From: Rich Felker <>
Subject: Re: R/GNU S: up with a couple hitches...

On Wed, Sep 19, 2012 at 12:44:41AM -0400, wrote:
> > On Tue, Sep 18, 2012 at 08:19:17PM -0400, wrote:
> >> BTW, Rich, here's what that page says about iconv:
> >> | The R usage requires iconv to be able to translate between "latin1"
> >> | and "UTF-8", to recognize "" (as the current encoding) and "ASCII",
> >> | and to translate to and from the Unicode wide-character formats
> >> | "UCS-[24][BL]E"
> >> How much of this should musl support?
> >
> > I've never heard of using "" (blank string) to mean "the current
> > encoding". If it's documented usage for glibc, it must be buried
> > somewhere in the docs; it's definitely not a standard usage. The
> > standard way to get the locale's encoding is nl_langinfo(CODESET); on
> > any good implementation it will be accepted as an argument to
> > iconv_open.
> Here's what the glibc docs say
> (
> ===
> The only locale names you can count on finding on all operating systems
> are these three standard ones:
> "C"
>     This is the standard C locale. The attributes and behavior it provides
> are specified in the ISO C standard. When your program starts up, it
> initially uses this locale by default.
>     This is the standard POSIX locale. Currently, it is an alias for the
> standard C locale.
> ""
>     The empty name says to select a locale based on environment variables.
> See Locale Categories.
> ===
> Not that they accurately represent facts outside glibc!

Those are _locale_ names. Nothing to do with charset names passed to


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.