Re: Collation implementation

[Paolo Bonzini <bonzi at pc-amo3 dot elet dot polimi dot it>]

> I'm still concerned about not basing the locale data in the C++
> library on the system's locale information (and, what's more
> important, on the names that the system uses for its locales).

The names are POSIX; as for Windows, Cygwin users (me included...) get
accustomed to incongruencies between Windows and Cygwin programs... and
usually like the Unix flavor better... :-)

You can however provide a decent default behavior by mapping the Windows
default LCID (locale id) to a POSIX-named locale.  It's just a few lines
of code and I can contribute it.

> Apart from that, I think having a reentrant GNU locale library is a
> good thing. Of course, it would take volunteer's time to create and
> maintain it...

Creating it is not so easy, because GNU libc uses a lot of GCC specific
things.  But it could be done indeed, and would be a good thing for
portability, at least as long as glibc is limited to Linux/Hurd systems:
At university we have Digital, HPUX, and Solaris machines, and I guess
this is not endemic to Italy.

I guess it should be also good to include gettext into a reentrant locale
library (many routines are shared by glibc locales and gettext).

As for maintenance, I guess it could/would be kept as part of glibc
(although in a separate tarball) once it has been created. You didn't say
whether glibc already uses __newlocale internally; if it does it would be
easy, but even if it doesn't it should be feasible to adopt it.

As for volunteering... I'm available, and you? :-)

What about asking Ulrich about the state/stability of the current glibc
CVS implementation of locales (as I said, collation support seems to be in
flux...)? He's usually pretty responsive and kind. I'd not fork a new
project if I have to sync every minute.

Regards,
Paolo