Re: OpenBSD locale system

[Ingo Schwarze]

Hi Bruno,

Bruno Haible wrote on Thu, Dec 20, 2018 at 09:55:25PM +0100:

> I have now submitted a request to add such a method to POSIX. Here:
> http://austingroupbugs.net/view.php?id=1220

Yes, i had seen that request.

> I used OpenBSD 6.2 as an example in there, not to bash OpenBSD,

Nothing is wrong with bashing OpenBSD when it is at fault.  ;-)

> but to prove that POSIX is incomplete so far. Which I should probably
> have done as early as 2005, when I noticed that the API is incomplete
> regarding GNU libc:
> https://sourceware.org/ml/libc-alpha/2005-03/msg00125.html

There can be no doubt that the POSIX locale system is incomplete in
many ways.  I do doubt that making it complete is feasible or even
desirable - trying to seems more likely to result in bloat than to
result in anything that might actually become complete in the end.

That said, i like the general approach of the ticket you submitted:
Do one very specific thing that can be argued to be particularly
important and that can also be argued to be a gap, because there
already is related functionality on more than one side:
setlocale(NULL) on one side, uselocale() on another side.

I'm not completely convinced the interface you propose is the best
design possible or really urgently needed, but i don't see off the
top of my head how to make it better (i.e. simpler), either.


I think i now see your point why setlocale(3) is not only useful to
configure the behaviour of *wc* and *mb* functions, but also for
standardized communication among various parts of a program, and
why something similar for uselocale(3) might possibly make sense.
Though i don't claim to anticipate all the dragons one might
encounter going that way.

[...]
> When you apply similar thought to LC_NUMERIC functionality, you can
> achieve good results. But I agree it's easy to introduce bugs in this
> area. Just last week, by mistake, I wrote code that prints a port number
> in a localized way: 8,080 or 8.080 depending on locale. Ouch.

Ouch indeed.  You strengthen my determination to oppose any support
for LC_NUMERIC and the like in OpenBSD.  We really don't want
functionality that makes bugs and vulnerabilities more likely, and
even less so when it only serves relatively arcane, rarely needed
purposes.  The unavoidable complexity of internationalized UI
programming must not introduce additional risks into pure-libc
systems programming.  Such stuff belongs into GUI programming kits,
not into libc.

[...]
> You would better look at a GNU gettext release:
> https://ftp.gnu.org/gnu/gettext/gettext-0.19.8.1.tar.gz
> There, in the gettext-runtime/intl/ directory, you will find the
> localename.c file - which is my attempt at overcoming the lack of
> a locale name getter function in POSIX - and its use for gettext().

Ah.  I hope you aren't offended that i won't study that code right
now in detail unless the following conclusion happens to be mistaken.
I suspect that i understand the situation well enough from your
short description to conclude that the bug might not be in gnulib
at all, but possibly rather in gettext.

On the one hand, gnulib seems right - without the patch you submitted
to this list - to detect that OpenBSD now provides uselocale(3).
So i'm not so sure the patch you submitted here is a good idea.

On the other hand, if i understand correctly what you are saying,
gettext expects some behaviour of newlocale(3) that isn't really
required by POSIX, and then jumps to conclusions about how the
locale_t objects returned from uselocale(3) can be used.  It seems
to me that, if gettext wants to use non-standard features of newlocale,
it is gettext that should test whether the specific extension features
it wants to use are available.  I'm not sure that is gnulibs task.
And even if people here think that doing *something* in gnulib to
help people deal with this situation makes sense, than disabling
the interface altogether looks like throwing the baby out with the
bathwater, when only specific non-standard ways of using the interface
are unsupported...

Also, a very brief look at localename.c in gettext gives me the
impression that it might be using an inconsistent mixture of (good)
feature tests and (always somewhat fragile) operating system name
tests.  For example, the function gl_locale_name_thread_unsafe()
appears to be compiled in and used without further conditions when
autoconf concludes HAVE_USELOCALE, but then the function doesn't
appear to do anything useful unless __GLIBC__, __FreeBSD__, or
__APPLE__ are defined.


Given that at least three different APIs to deal with the task you
are describing in the Austin group ticket are already implemented
in various operating systems, this is likely not the best time to
implement any additional functionality in OpenBSD.  A better time
for doing so might be when the dust has settled and the Austin group
has made a descision which among the several options will be
considered the standard one.  In particular since your goal of
having a standard way to communicate among various parts of a program
can hardly be reached anyway, as long as there are several competeting
tools and none of them generally available.  Besides, locale support
certainly isn't the focus of OpenBSD development goals, so a "wait
and see what other free projects more invested in this particular
business can agree on" looks like a somewhat reasonable approach
to me.

Yours,
  Ingo