From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12097 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: setlocale behavior with 'missing' locales Date: Sun, 12 Nov 2017 19:15:44 -0500 Message-ID: <20171113001544.GZ1627@brightrain.aerifal.cx> References: <20171108050338.GL1627@brightrain.aerifal.cx> <20171108052715.GM1627@brightrain.aerifal.cx> <5A08C907.2010209@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1510532160 28881 195.159.176.226 (13 Nov 2017 00:16:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 00:16:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12113-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 13 01:15:55 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eE2Po-00077k-Mt for gllmg-musl@m.gmane.org; Mon, 13 Nov 2017 01:15:52 +0100 Original-Received: (qmail 5311 invoked by uid 550); 13 Nov 2017 00:15:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5287 invoked from network); 13 Nov 2017 00:15:57 -0000 Content-Disposition: inline In-Reply-To: <5A08C907.2010209@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12097 Archived-At: On Sun, Nov 12, 2017 at 04:19:51PM -0600, A. Wilcox wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/11/17 23:27, Rich Felker wrote: > > One notable issue is that, right now, we rely on being able to set > > LC_MESSAGES to an arbitrary name even if there's no libc locale > > definition for it; this is because gettext() relies on the name of > > the current LC_MESSAGES locale to find (application-specific) > > translation files that might exist even without a libc translation. > > I'm not sure how we would best keep this working under changes > > similar to the above. > > I can think of two ways to handle it, but neither of them are all that > great: > > 1) Provide simple translations for the most common 90% of languages. > Some people are getting unfairly screwed here, but they are probably > getting screwed by every other app/library as well. It should be very > simple to find a list of month names and abbreviations online for > pretty much any language (even using Wikipedia's month article > translations or Microsoft's Open Software Translations project). This is an interesting idea I once considered, but it has too many problems. It's a large volume of data that would be duplicated in every static-linked application, and at least some of it would become outdated or would be subject to user disagreement about what it should be -- things like time formatting, radix separator (if we make it variable at all), etc. Also the category in question is LC_MESSAGES, which has nothing to do with dates but rather strerror messages and such. Having default translations for these for all languages linked into libc really does not make sense. > 2) Use an access(3) call for /usr/share/locale/$LC_MESSAGES. This > means there is virtually no work for musl beyond adding the call, and > it will only succeed if the locale is available (which is exactly what > the standard demands). The two problems I see with this is: access() is generally always wrong (uses wrong permissions when real & effective ids differ), but that's a minor detail. However I don't see how this tells you anything useful. All it tells you is whether at least some application installed in the given prefix (here /usr) has translation files for the particular locale name. It doesn't tell you whether the running application does (false positives), nor does it tell you whether applications with different prefixes might (false negatives). > 1) if /usr/share is NFS shared this could lock. > But it would do so anyway if setlocale(3) succeeded. > > 2) it requires use of stdio which most people on this list hate. I don't see what relation it has to stdio. Rich