Date: Sun, 12 Nov 2017 19:15:44 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: setlocale behavior with 'missing' locales 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
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.