From: Alastair Houghton <firstname.lastname@example.org>
Cc: Rich Felker <email@example.com>
Subject: Re: [musl] setlocale() behaviour
Date: Fri, 21 Jul 2023 11:48:10 +0100 [thread overview]
Message-ID: <0269D5BF-89D3-4D34-8BF7-62D3CB67630E@apple.com> (raw)
Rich, any chance of some input from you on this, since it was you that wrote about it previously?
On 19 Jul 2023, at 18:10, Alastair Houghton <firstname.lastname@example.org> wrote:
> As Rich Felker noted previously about this behaviour:
>> Unfortunately this turns out to have been something of a tradeoff,
>> since there's no way for applications (and, as it turns out,
>> especially tests/test suites) to query whether a particular locale is
>> "really" available. I've been asked to change the behavior to fail on
>> unknown locale names, but of course that's not a working option in
>> light of the above.
> He then went on in a subsequent message to the list to suggest
>> 1. setlocale(cat, explicit_locale_name) - succeeds if the locale
>> actually has a definition file, fails and returns a null pointer
>> 2. setlocale(cat, "") - always succeeds, honoring the environment
>> variable for the category if a locale definition file by that name
>> exists, but otherwise (the unspecified behavior) treating it as if
>> it were C.UTF-8.
> Which would work just fine for libc++. What it’s trying to do is to check whether e.g. fr_FR is supported, then it can enable additional tests that rely on the French localisation being present. I appreciate that, per the POSIX standard, you don’t *technically* know what fr_FR means, but in practice that isn’t really true --- an implementation that had a locale installed called fr_FR that *wasn’t* French would be pretty silly. Unfortunately, because of musl’s current behaviour, it *looks like* such an implementation, even though it actually isn’t (and it totally could have a genuine fr_FR locale if you had the right data in the right place).
> I can, of course, check whether setlocale(LC_ALL, “something ridiculous”) succeeds and returns “something ridiculous”, then disable all locales except for POSIX, C and C.UTF-8. That will work around the current musl behaviour without causing trouble with other C libraries, but libc++’s maintainer isn’t terribly keen on it and would rather we explore the possibility of musl changing its implementation.
> TL/DR: What I’m really enquiring about here is the fact that there was discussion about changing it to work in a more useful manner, but nothing changed (and I don’t see anything in that email thread to explain that it was decided to not make the proposed change; but maybe I missed it?)
> Kind regards,
prev parent reply other threads:[~2023-07-21 10:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 8:30 Alastair Houghton
2023-07-19 16:51 ` Markus Wichmann
2023-07-19 17:10 ` Alastair Houghton
2023-07-21 10:48 ` Alastair Houghton [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).