[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260917203006.GL23438@brightrain.aerifal.cx>
Date: Thu, 17 Sep 2026 16:30:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Locale merge status
On Tue, Sep 15, 2026 at 09:28:18PM -0400, Rich Felker wrote:
> 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.
I've got these partly done (all done on the tooling side, some missing
stuff on musl side) but I found another oversight:
localeconv() result is not a constant function of a single loaded
locale, but the combination of LC_MONETARY from one and LC_NUMERIC
from another potentially different one. So it can't reside as constant
data built at load-time from a single locale. It has to be dynamically
derived at setlocale/newlocale time.
This actually isn't all that bad, and may even reduce typical memory
usage in the case where all LC_* aren't the same. It did require
reshuffling a few things but I've got it implemented now and think the
result is clean. And it avoids pulling in any code to update these
(tho not the .data or malloc size for them) in static programs if
localeconv() is not referenced, as I was planning:
> - 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.
