[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20260916012817.GA18637@brightrain.aerifal.cx>
Date: Tue, 15 Sep 2026 21:28:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Locale merge status
I'm working on a series of integration patches for bringing the new
locale functionality into musl. This will only be merged to mainline
after an upcoming bugfix release, but I will post an evaluation branch
or git-format-patch patch series before that.
So far, I have musl loading a locale in the new format and doing error
message translations, localeconv sturcture, and nl_langinfo lookups
from it. Collation functions are not yet integrated, but will be next.
I still need to refactor them a bit to do the wchar versions.
A few previously-overlooked or -forgotten things came up in the
process, which will need to be addressed:
- strsignal strings were never added to the source or binary format.
While these mostly admit a canonical numbering we're already using,
some archs replace SIGSTKFLT with SIGEMT or have no such signal.
These cannot just use the same message slot because then the locale
files would be arch-specific; instead we need to reserve a number
for SIGEMT that doesn't clash with anything else. The reasonable
thing to do is probably to start assigning oddball-arch signals
(afaik these are only mips) at -1 and working downward.
- getopt has a couple strings ": unrecognized option: " and
": option requires an argument: ", which need translation and which
were previously covered by the old gettext system. I think these
need a new "libc implementation-specific message strings" table,
where ldso messages would eventually go too.
- nl_langinfo has a few keys that are duplicates or derived from lconv
data, at least CRNCYSTR and RADIXCHAR. While RADIXCHAR could just be
read from the equivalent lconv field, that requires special-casing
it in nl_langinfo, which locks us into having larger code. And
CRNCYSTR ia a modified version of lconv's currency_symbol with a +,
-, or . prefixed onto it based on p_cs_precedes and n_cs_precedes,
which would require writable storage to dynamically construct if the
memory-mapped locale file does not provide it separately. So I think
we should add these keys to the locale file.
Some things to make lighter:
- __c_dot_utf8, the builtin object for the UTF-8 locale, gets
gratuitously large with all of the fields to be a real locale with
its own struct lconv, pointers for easy access to subtables, etc.
Since none of this data will ever be accessed for LC_CTYPE, and
since it never needs to be set for anything but LC_CTYPE (in all
other categories, it acts as "C"), it can be one of a smaller struct
at the start of the full struct, nothing but a string with its
locale name, or a fake pointer like (void *)-1 just for the
is-non-null checks to see it. In the latter case, things that peek
at the locale name would need to special-case it, which might be
annoying.
- While the code isn't terribly large, it probably makes sense to make
it so the initialization of lconv doesn't happen unless localeconv
is linked, and so initialization of the collation pointers doesn't
happen unless collation functions are linked, etc. This would help
keep static programs that just do setlocale(LC_CTYPE,"") to get
working UTF-8 as small as possible. Improvements like this, using
weak symbols and code moved to the places it's needed, could be made
far later in the release cycle after initial merge though.
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.
