Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Jan 2020 09:28:33 -0500
From: Rich Felker <>
To: Abdessattar Sassi <>
Subject: Re: Implementation of built-in locale only allows for
 'C.UTF-8' and fails with just 'C'

On Thu, Jan 16, 2020 at 05:53:42PM +0400, Abdessattar Sassi wrote:
> Hi,
> I run into a problem compiling a C library into WASM using emscripten,
> which in turn uses libmusl.
> The library calls 'locale_t __newlocale(int mask, const char *name, locale_t
> loc)' with name being "C".
> the implementation in musl calls __get_locale() with val being "C":
> -- extracted from locale_map.c:
> int builtin = (val[0]=='C' && !val[1])
> >       || !strcmp(val, "C.UTF-8")
> >       || !strcmp(val, "POSIX");
> > if (builtin) {
> >       if (cat == LC_CTYPE && val[1]=='.')
> >             return (void *)&__c_dot_utf8;
> >       return 0;
> > }
> If I understand that code correctly, it will return 0 (fail) if the name is
> just "C" and not "C.UTF-8".
> Is this the intended behavior? (note that glibc and others do NOT require
> the .UTF-8, a simple 'C' works just fine and many existing code relies on
> that).
> Thank you.
> *Please Cc: me in reply.*

__get_locale is not a public function; its internal contract is that
it returns 0 for the C locale. This is not an error condition. If
newlocale is failing then the problem is somewhere else. Do you have a
test case to reproduce the failure?


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.