From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24532 invoked from network); 21 Jul 2023 10:48:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2023 10:48:38 -0000 Received: (qmail 24559 invoked by uid 550); 21 Jul 2023 10:48:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24527 invoked from network); 21 Jul 2023 10:48:32 -0000 X-Proofpoint-ORIG-GUID: ZSQiMNgDu7RZQ7I7glmsJfyeixHpBXXx X-Proofpoint-GUID: ZSQiMNgDu7RZQ7I7glmsJfyeixHpBXXx X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-11_09:2023-07-11,2023-07-11 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307110153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=Eb1w145GmugTggBgh9yPRSPCVBUJAt13zpRpL1LZI9E=; b=Z2Nhc8/NqUa1FcUflX+DguPFqfYjnqauqoXWSYy6+HtoVzLzPRyGSAQk4V8dXTeDfIMb spydljJoKOyIFZxQYgpqF5JNJ63lJbUL62uxfREUVWltN39INxolPha6VcVjjw7JLmlS n8QOVJflbJf8hRZemRG5/E6CTRlPVMVIPotuVlC9ZV+i7peoWnb9n74HuWsI8ZoVBvFZ /rIphdh0rEvJRiTpzh9mRv6Km4LJA40HUT0gBznFY7MVe0flH07u8d0oIfmMfkiA2A10 ymxyypKtiBVDxek8KP74xHXMGol+JGKcgNqMagCEEWRZhGxxMeyuqWZgrzi2tY+RlUk/ 0w== X-Va-A: X-Va-T-CD: 14dc138f66d48087821ca031f1b11e6a X-Va-E-CD: f96c7fe1e97f4ac5299011733ae8751d X-Va-R-CD: 4d29c8d1aa54e20f4ea2a6a37d633d6c X-Va-ID: 12559b99-f6eb-420b-873c-cf98095cfd2b X-Va-CD: 0 X-V-A: X-V-T-CD: 14dc138f66d48087821ca031f1b11e6a X-V-E-CD: f96c7fe1e97f4ac5299011733ae8751d X-V-R-CD: 4d29c8d1aa54e20f4ea2a6a37d633d6c X-V-ID: 8bfd5764-9834-443a-babf-af2c83896904 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-21_06:2023-07-19,2023-07-21 signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 16.0 \(3769.100.3\)) From: Alastair Houghton In-reply-to: <5E20CC9B-57C5-47D5-88F1-5CD8727B421F@apple.com> Date: Fri, 21 Jul 2023 11:48:10 +0100 Cc: Rich Felker Content-transfer-encoding: quoted-printable Message-id: <0269D5BF-89D3-4D34-8BF7-62D3CB67630E@apple.com> References: <92D1805E-DEAE-4BB4-94F0-38EB24F2EE33@apple.com> <5E20CC9B-57C5-47D5-88F1-5CD8727B421F@apple.com> To: musl@lists.openwall.com X-Mailer: Apple Mail (2.3769.100.3) Subject: Re: [musl] setlocale() behaviour Rich, any chance of some input from you on this, since it was you that = wrote about it previously? Kind regards, Alastair. On 19 Jul 2023, at 18:10, Alastair Houghton wrote: >=20 > As Rich Felker noted previously about this behaviour: >=20 >> 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. >=20 >=20 > He then went on in a subsequent message to the list to suggest >=20 >> 1. setlocale(cat, explicit_locale_name) - succeeds if the locale >> actually has a definition file, fails and returns a null pointer >> otherwise. >>=20 >> 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. >=20 > Which would work just fine for libc++. What it=E2=80=99s 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=E2=80=99t *technically* = know what fr_FR means, but in practice that isn=E2=80=99t really true = --- an implementation that had a locale installed called fr_FR that = *wasn=E2=80=99t* French would be pretty silly. Unfortunately, because = of musl=E2=80=99s current behaviour, it *looks like* such an = implementation, even though it actually isn=E2=80=99t (and it totally = could have a genuine fr_FR locale if you had the right data in the right = place). >=20 > I can, of course, check whether setlocale(LC_ALL, =E2=80=9Csomething = ridiculous=E2=80=9D) succeeds and returns =E2=80=9Csomething = ridiculous=E2=80=9D, 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++=E2=80=99s maintainer = isn=E2=80=99t terribly keen on it and would rather we explore the = possibility of musl changing its implementation. >=20 > TL/DR: What I=E2=80=99m 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=E2=80=99t see anything in that email = thread to explain that it was decided to not make the proposed change; = but maybe I missed it?) >=20 > Kind regards, >=20 > Alastair. >=20 >=20 >=20