[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <111887e30a6f9e6b0f206855068c32f47be6086a.camel@postmarketos.org>
Date: Wed, 23 Sep 2026 15:51:38 +0200
From: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
To: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: [PATCH] [RFC] musl locale overhaul series, take 1
Hi Rich,
El Mon, 21-09-2026 a las 12:51 -0400, Rich Felker escribió:
> The attached patch series is the current contents of my integration
> branch for the locale support overhaul project, funded by NLnet and
> the NGI Zero Core Fund. I'm sending it out now for review and testing
> by folks doing localization or anyone else who would like to poke at
> this.
>
> The attached series is factored into a number of small commits to be
> easily reviewable now and long-term in the history; in terms of
> behavioral changes, what it includes are:
>
> - Updates of built-in character data to Unicode 17. This is entirely
> mechanical, generated by musl-chartable-tools[1], probably not
> intersting to read.
>
> - Code to process the new locale file format, and changes to switch
> over to using it.
>
> - No longer synthesizing dummy locales for requested locale names that
> don't exist. setlocale(cat,"") still succeeds in this case but the
> resulting locale name will be C.UTF-8. Explicit requests for a name
> result in failure.
>
> - Linear-search-free versions of all of the error message lookup
> interfaces (strerror, hstrerror, gai_strerror, regerror) using the
> new string table lookup infrastructure for both built-in and locale
> string tables.
>
> - Linear-search-free and lookup-key-collision-free version of
> nl_langinfo, the backend for localized date/time formatting, using
> the same string table infrastructure as error messages now use.
>
> - Collation interfaces (strcoll, strxfrm, wcscoll, wcsxfrm) that pass
> conformance test vectors with the CLDR root data. This includes the
> NFD iterator and decomposition tables (large) which are generated by
> the musl-uca-draft[2] tooling.
>
> - localeconv implementation that reports LC_NUMERIC and LC_MONETARY
> properties set in the locale file.
>
> - strfmon implementation that honors LC_MONETARY properties to format
> monetary quantities.
Thanks a lot! These look good, I'll work on integrating musl-locales with this
patch-series.
>
>
> It is still missing a couple small details that are regressions from
> the old system:
>
> - strsignal is missing translated signal names. It needs a small
> amount of additional logic to translate arch-specific signal numbers
> to a common numbering for lookup.
>
> - getopt is missing translated error strings. This was an oversight I
> need to go back to finish due to the old code calling the __lctrans
> function directly rather than using the macro that's used everywhere
> else, which I grepped for.
I think this is specially unfortunate since I indeed sent a patch to fix that
more than a year ago, that laid in the list without any response:
https://www.openwall.com/lists/musl/2025/06/02/1
>
> These will probably be done in the next couple days but I wanted to go
> ahead and get this series out for more eyes.
>
>
>
> There are also a few "stretch goals" that may or may not make it in
> immediately. Some of these were items where design of the new locale
> format to ensure that it can represent them and avoid locking us out
> of future support was in-scope for the project, but adoption was TBD:
>
> - Support for alt numbers and month names in date/time formatting.
> These were originally not supported in musl, and part of this is new
> in POSIX 2024 which we still need to catch up to in general. But
> they don't look difficult to add.
>
> - Support for grouping ("thousands separator") and alternate radix
> point character in printf, and the latter in scanf/strtod. If the
> radix character is done, it will be restricted to only allowing '.'
> or ',' so that applications are not forced to deal with ambiguous or
> multibyte radix.
>
> - Bringing gettext behavior at least partly up in line with
> standardization into POSIX 2024. This will balance out with losing
> support for "synthesized"/fake locales in LC_MESSAGES by letting
> users set the LANGUAGE environment variable to get localized gettext
> messages for the application even when libc doesn't have a locale
> for their language yet.
>
> - Setting a policy for a default locale search path. My leaning is
> choosing a non-colliding name under /etc, to be configurable as a
> symlink to the actual install location rather than hard-coding some
> specific location.
There was probably some miscommunication here, but setting this was a core part
of the project as described and agreed in
https://www.openwall.com/lists/musl/2025/06/02/2 so let's discuss it now :)
The two biggest standards that exist around filesystem hierarchies, the FHS[1]
and the LFSH[2] define /etc as "Host-specific system configuration" and "System-
specific configuration" respectively. IMHO, locales and collation rules are not
system some host-specific or system configuration, but a core part of the C-
library.
So potential alternatives that I believe would fit:
* /usr/share/musl, which would be compliant with both the FHS and LFSH, as
architecture-independent package or system data
* Directly under /lib or /lib/musl. Although less compliant with the standards,
this would avoid the /usr prefix, and would place the localization data right
next to the library. This is not an uncommon pattern, and something similar to
what apk-tools does for its database
If sysadmins wish to modify the locales, we could either keep honoring a
environment variable, or give /etc/musl precedence for searching locales than
the other path. I personally got no opinion on what is best here.
Best,
Pablo
[1] https://specifications.freedesktop.org/fhs/latest/
[2] https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/
>
>
>
>
> [1] https://github.com/richfelker/musl-chartable-tools
>
> [2] https://codeberg.org/dalias/musl-uca-draft
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.
