[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <767ed1bd87af1ace778169536de1296a8138120b.camel@postmarketos.org>
Date: Wed, 29 Nov 2023 00:21:37 +0100
From: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
To: Alastair Houghton <ahoughton@...le.com>, musl@...ts.openwall.com, Rich
Felker <dalias@...c.org>
Subject: Re: setlocale() again
On mar, 2023-11-28 at 17:32 +0000, Alastair Houghton wrote:
> > On 18 Sep 2023, at 15:18, Alastair Houghton <ahoughton@...le.com>
> > wrote:
> >
> > Hi all (Rich especially though :-))
> >
> > Has anyone had time to take a look at this? I’d like to make some
> > progress on this front if possible.
> >
> > Kind regards,
> >
> > Alastair.
>
>
> Maybe I’ve missed a reply somewhere along the lines; here’s a
> tentative patch that just does the simple thing of making
> setlocale(LC_ALL, "") pick the C.UTF-8 locale if it’s unable to find
> the locale specified in the environment.
Hi Alastair,
>From the logic of the change, and from the postmarketOS perspective,
would be fine be me if Rich does not commit this right before a
release, as otherwise we would not have much time to inform and help
less technical users get their localization back. Now is probably a
great time, since the new alpine release is around the corner.
However, this also increases the importance of musl-locales for
localization to work at all. Before, its existence as a completely
independent project was totally fine, users would not need it to get a
localized system. However, after this change, that's no longer the
case. So I wonder if Rich or the musl community in general would like
to host/take care for it? Maybe even deciding on a standar locale path
that does not need to be set through an environment variable, though
keeping that as a fallback? I'd love to see that come together with
this change.
Best,
Pablo.
>
> This will mean that setlocale(LC_ALL, "non-existent locale") will
> return NULL, which does have an impact on users if they don’t have a
> locale installed for Musl but *do* have locale data installed for
> some other software; in that case, their other software won’t be
> localized until they also install data for Musl.
>
> (This is the same as current Glibc behaviour.)
>
> Kind regards,
>
> Alastair
>
> ---- snip ----
>
> diff --git a/src/locale/locale_map.c b/src/locale/locale_map.c
> index da61f7fc..bd11f2ca 100644
> --- a/src/locale/locale_map.c
> +++ b/src/locale/locale_map.c
> @@ -31,7 +31,7 @@ static const char envvars[][12] = {
> volatile int __locale_lock[1];
> volatile int *const __locale_lockptr = __locale_lock;
>
> -const struct __locale_map *__get_locale(int cat, const char *val)
> +const struct __locale_map *__get_locale(int cat, const char *locale)
> {
> static void *volatile loc_head;
> const struct __locale_map *p;
> @@ -39,6 +39,7 @@ const struct __locale_map *__get_locale(int cat,
> const char *val)
> const char *path = 0, *z;
> char buf[256];
> size_t l, n;
> + const char *val = locale;
>
> if (!*val) {
> (val = getenv("LC_ALL")) && *val ||
> @@ -92,18 +93,9 @@ const struct __locale_map *__get_locale(int cat,
> const char *val)
> }
> }
>
> - /* If no locale definition was found, make a locale map
> - * object anyway to store the name, which is kept for the
> - * sake of being able to do message translations at the
> - * application level. */
> - if (!new && (new = malloc(sizeof *new))) {
> - new->map = __c_dot_utf8.map;
> - new->map_size = __c_dot_utf8.map_size;
> - memcpy(new->name, val, n);
> - new->name[n] = 0;
> - new->next = loc_head;
> - loc_head = new;
> - }
> + /* If no locale definition was found, and we specified a
> + * locale name of "", return the C.UTF-8 locale. */
> + if (!new && !*locale) new = (void *)&__c_dot_utf8;
>
> /* For LC_CTYPE, never return a null pointer unless the
> * requested name was "C" or "POSIX". */
>
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.
