mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Pablo Correa Gomez <pabloyoyoista@postmarketos.org>
To: Alastair Houghton <ahoughton@apple.com>,
	musl@lists.openwall.com, Rich Felker <dalias@libc.org>
Subject: Re: [musl] setlocale() again
Date: Wed, 29 Nov 2023 00:21:37 +0100	[thread overview]
Message-ID: <767ed1bd87af1ace778169536de1296a8138120b.camel@postmarketos.org> (raw)
In-Reply-To: <25283A51-7FB1-4CB1-9C26-DF06F69922BC@apple.com>

On mar, 2023-11-28 at 17:32 +0000, Alastair Houghton wrote:
> > On 18 Sep 2023, at 15:18, Alastair Houghton <ahoughton@apple.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". */
> 


  reply	other threads:[~2023-11-28 23:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 15:41 Alastair Houghton
2023-08-10 15:51 ` Rich Felker
2023-09-05 12:57   ` Alastair Houghton
2023-09-18 14:18     ` Alastair Houghton
2023-10-27 20:15       ` Pablo Correa Gomez
2023-11-28 16:27         ` Alastair Houghton
2023-11-28 23:15           ` Pablo Correa Gomez
2023-11-28 17:32       ` Alastair Houghton
2023-11-28 23:21         ` Pablo Correa Gomez [this message]
2023-12-05 15:19         ` Alastair Houghton
2023-12-08 10:46           ` Alastair Houghton
2023-12-08 23:59             ` Rich Felker
2023-12-09 18:44               ` Pablo Correa Gomez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=767ed1bd87af1ace778169536de1296a8138120b.camel@postmarketos.org \
    --to=pabloyoyoista@postmarketos.org \
    --cc=ahoughton@apple.com \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).