Hi Ingo,
> The OpenBSD C library intentionally doesn't implement any other
> locale(1) categories except LC_CTYPE because many here regard the
> other categories as overengineering and as detrimental to system
> security
I partially agree with this, regarding specific categories, such as
- LC_MONETARY: The main API function for this category, strfmon(),
is defined in such a way that, if implemented correctly, it
produces misleading results.
<http://austingroupbugs.net/view.php?id=1199>
- LC_PAPER: Any software which wants to print something should
better ask the attached printer, rather than make assumptions
about the printer device based on the locale.
However, locale categories such as LC_NUMERIC and LC_MESSAGES
are useful when you assume that your software does have end-users
that are not sysadmins.
For Android, the choice to use dumbed-down locales in libc was made
because 99% of the software visible to the end user is written in
another programming language (Java) that comes with its own, elaborate,
locale system. The remaining 1% of visible only to developers via 'adb',
and thus needs no locales.
Regarding OpenBSD, the uselocale support is useful for adding a checkmark
to the checkbox "We support POSIX locale_t API", but is not useful, for
example, to have a multithreaded web server honor the Accept-Language
settings given by a browser user, other than by reimplementing all
needed locale-dependent behaviour.
> POSIX does not require that "de_DE.UTF-8" and
> "fr_FR.UTF-8" must be different locales, or that they behave
> differently from each other in any way.
Here you need to distinguish
- locale-dependent behaviour defined by POSIX functions and
- locale-dependent behaviour defined by the application.
In setlocale.c you made this distinction, as witnessed by the comment in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/locale/setlocale.c?annotate=1.29
lines 72..75.
Why not also for the per-thread locales? By implementing the FreeBSD
querylocale API (the equivalent of setlocale(category,NULL) for locale_t
objects), you would make it possible for applications to pull out
German versus French messages, depending whether the per-thread locale
is "de_DE.UTF-8" or "fr_FR.UTF-8".
> Not sure what the conclusion should be for gnulib - it probably
> depends on what gnulib suggests the application build system should
> do when newlocale(3) is not available
Exactly. Gnulib now treats such a platform like one which does not
have locale_t, uselocale(), newlocale().
Bruno
