On Thu, May 08, 2014 at 12:07:30PM +0200, Stefan Sperling wrote:
> On Wed, May 07, 2014 at 07:44:51PM +0200, Ingo Schwarze wrote:
> > While LC_CTYPE and LC_COLLATE make some sense, LC_MONETARY, LC_NUMERIC,
> > and LC_TIME are badly overengineered, pointless bloat, causing nothing
> > but surprising, erratic behaviour and portability problems when trying
> > to parse output from programs. I think this should be rejected outright
> > and you should stop wasting your time on it.
>
> They make sense for systems that try to provide full i18n.
> Of course, we don't try to provide i18n, at least not for the base system
> which is English only. So they don't really make sense *for OpenBSD*.
???
Basic support for that stuff makes sense, as part of a *full* libc.
Not surprisingly, Antoine is for providing LC_* support. So am I.
This has little to do with "base OpenBSD", everything to do with "enough
stuff to be able to compile reasonable portable software on OpenBSD
without needing to patch left and right".
As for portability issues: programs stay with the C locale *in any case*
unless they do setlocale("") right at the start, in which case they
explicitly say "yes, I want to be localized". So, from that point of view
the portability issues are minimal (yes, I'm aware of the can of worms
that threads+locale may open).
> That said, I don't have a general problem with adding other locale categories.
> I believe LC_TIME would provide a useful testbed for eventually switching all
> our
> locales to the localedef format (including LC_CTYPE). Alas, the proposed diff
> does something else, and unfortunately I don't have enough time for a detailed
> rabbit hole discussion and review with a lot of back-and-forth that we had
> when
> discussing similar diffs in the past.
THAT on the other hand is the issue at hand... chronic time shortage to be
certain that what we do for locales isn't dangerous...
