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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 10639 invoked from network); 19 Jul 2023 16:51:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Jul 2023 16:51:29 -0000 Received: (qmail 20440 invoked by uid 550); 19 Jul 2023 16:51:25 -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 20402 invoked from network); 19 Jul 2023 16:51:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1689785473; x=1690390273; i=nullplan@gmx.net; bh=ONoh/g0ghGvRcyjiQYJiTAoap0lNYCzTEPBVtgzQk+8=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=Nq7Jl7cIu734UjAEf8YRkJfvA0nJ+wef8bHQ/UPTDUfsFUXe9ujuy3XQgB6s7GMtmLenHVq PhjNZRGH+Q/WBeOxXqtzuJHmvALUDztrtTekeQHRwudtBuCsRDGlvlW39LpnjzXOYMKGKWzta BjnV+SYioOJdH3xq1bze0IEDEHcAReN7KGKntEG7EBIFQ8x3xkKTnl/QzNhIwSrjzg25QEVLM rys/duWpmlTADnNhMb5pd34lrD/KEPcjwhMLUfTl2fhla4mi3+CnSxEqIY2k6O4HNO8OS5ZJi kJ9KyqM33mDZjraXU687+7P2ZnGJK5OCJj2DxJeD/VVg6f7Fpysw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Wed, 19 Jul 2023 18:51:12 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <92D1805E-DEAE-4BB4-94F0-38EB24F2EE33@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <92D1805E-DEAE-4BB4-94F0-38EB24F2EE33@apple.com> X-Provags-ID: V03:K1:l+dWNyghGLVX4aEygZsieZ4HmlUiUKmMBZuwDTuxQg6q/4GZSp6 K9ird3URguMwArFx9Lq8d9WeqV/kLcM95EYb8Y7phQZdzfR/AWpYbXFl08ScWYIzNdAozPY huze8yUJbgYbrO4/dTS/X+kQleMYF1Gl9BBxZZJ52uNRhYSuUxo446UbG1YGZK7uWcjTGoc x4bt5fCjjOm2KXNcHJRaQ== UI-OutboundReport: notjunk:1;M01:P0:PWJXJgMQutE=;bXYJugoS8itcwj8Exip09la6wwQ 4U7/AeQ1Tp2TETGzYmgQENFHCr09nv91So+dEHrPqmHi28iqXKbMVXeOyBwXN4yUMH7DHHI9I i6wj0Hj2FeFqpoOeZ/xWTVRndNpQHulH7oe+lY/BxOJiWG0GmWafr27eF2JQ+ZWpzf9U9AyET wpFP9wA3/UsCBcuYygTl2SpzMNgSjlhPc5ZfdE62YQBelfxJl/BSylWH9Zzqf7H+2UtMXsFji o/j7w1/ezRcklMhgPYJMAy2P5vFyoFQYQ9M0bwxc5WCveK33SItPu632xDzucyVO9XrwyhIwi IOjo7n+i5jPGtwwv6ORxNrhhv+/P3Lh0ieiDjjWzNp8adjb4hY+UyPeXfhhK7BePU3gn/rFur Vo0nwxAyeMLvp40cRAe98PXxyLxGXzH7zzfIgCdIrrFtZFjN5AVlwQb9OYnnn/FscBNbYu6vC PpMq/R20YYdFaw+oYCDnFolVEKWqnAEXjEV3dbXQ2piTrLnRyoyTeqIpG3aamDiogxhurORec iaKNHdLmV/jGCxWXzoRi9Vis9Sv7XZfiBm0ABNIhCEhWAV+hFMnM2q8Ji3UOHxekrpP4Mcc3g f00rT3R46oGpmbtvfpKqRbUbaCr1YbqRPvwVkvIpy8YUg3GYFxE7PBAe1sx6gDfo1oczpCiVd VvH8b8Hd/YcikH2ZFyEHvMudMMMxXWwnCbXGE2bmH4VV1eh5YjwYiGQU6HYw4544rv5mbzexA P+6mMGj690eMoVCQoksEgtAbzE3pNweIobsRLa5UrR3wHiaSmVVJi28fA75p1SYafAlv21N1F AI571Lo2P5qUu54be5DEDEhAuicHg8RPrD902Rvm3zRs/K4kQeKaoF7PT6pYPxSGx7Q2iMPVe EV+jxlkKX7LxDgDcw6/ng2Ieg+lgbjXo82mZkn19ZzOZIO60MUB+k5lR/ZEd4chTjCtxhikxw fgXBdtSDsmaMt3Xb5s9GNZ5AVBE= Subject: Re: [musl] setlocale() behaviour Am Wed, Jul 19, 2023 at 09:30:08AM +0100 schrieb Alastair Houghton: > Hi there, > > Presently, musl=E2=80=99s setlocale() function essentially always succee= ds, even if it doesn=E2=80=99t actually have data for the requested locale= . I note the previous message to the list in 2017 > > > > discussing potential solutions, but unless I=E2=80=99m much mistaken not= hing has really changed in the code? > > This has come up because the test rig for libc++ tries to detect which l= ocale data is installed so that it can run its own locale support tests (i= t=E2=80=99s trying to test the C++ locale support that it has constructed = atop the C library=E2=80=99s underlying locale support). If, for instance= , you don=E2=80=99t have data for fr_FR installed, libc++ won=E2=80=99t ru= n test cases that rely on that data. On other C library implementations, = that=E2=80=99s easy because setlocale() will return NULL in such a case, b= ut musl doesn=E2=80=99t do that - instead, it sets up a copy of C.UTF-8, n= ames it fr_FR and sets that as the current locale :-( > > Kind regards, > > Alastair. > Well, you must not depend on implementation internals. According to POSIX, the form of the locale environment variables and the strings to be plugged into setlocale() (except for "POSIX", "C", "", and the null pointer) are implementation-defined, and musl defines that absolutely any name is supported and is a copy of C.UTF-8 (again, except for "POSIX" and "C"). The name handed in must be returned back out again for gettext to work. POSIX talks about the form of those variables in the XSI extension, but only such that it allows variables to have that form (that being lang_COUNTRY.codeset@modifier), and the precise meaning is again left to the implementation. What do the test cases for libc++ depend upon that is not fulfilled without the localization data? Ciao, Markus