Hi, everybody,

I've been looking into giving some updates to certain interfaces that
may be useful and uselocale was one of the first I thought---not the
first, but the first for which I send a patch.

Currently, i18n.c reads:
  /* XXX: We don't define it as `LC_GLOBAL_LOCALE' because of bugs as of
     glibc <= 2.11 not (yet) worked around by Gnulib.  See
     http://sourceware.org/bugzilla/show_bug.cgi?id=11009 for details.  */

I've checked the bug, and I think that the current behaviour of libc is
completely compliant with POSIX.  The only two positive mentions to
LC_GLOBAL_LOCALE I've found are in uselocale[1] and duplocale[2]
specifications, and the third explicitly says that it is undefined
behaviour to provide it to newlocale[3] or freelocale[4].  I consider
that they provide a complete framework for the use of this special
object.

In addition, exposing that kind of interface to the Scheme world seems
quite forced, from my point of view.  I propose an interface for
uselocale that deduplicates the information from the unique return
value, that is mandatory in the cold cold C world, to *two* values:
first a boolean, that indicates if there is/was a thread-specific locale
installed, and the locale in use before the call as the second value.

If it's called without parameters just returns the value, while the
following call:
   (uselocale #f)

Is equivalent to the cryptic:
   setlocale (LC_GLOBAL_LOCALE);

The usual interface:
   (uselocale anything-not-false)

Provides a locale object that will be installed in the current locale,
or fails if the type is not the adecuate or other system reason, of
course.  The returned value is always a smob that must enter the GC
world, so the call to duplocale is needed anyway.

Nonetheless, one of the main use cases would be the guarded execution
idiom, so I also expose an interface called 'with-thread-locale'.  The
current implementation is in C with dynamic-wind underneath and a simple
macro over it, but the documentation contains a possible implementation
in Scheme too.

It's only implemented it under USE_GNU_LOCALE_API and needs more work to
be completely ready, as probably the function should be moved to the
posix module (?), but the code it's working---as always, on my machine.

And as a secondary ramification, looking into the other condition (when
USE_GNU_LOCALE_API is not defined) I found something that seems to be a
memory leak, but I don't know where to test it---I don't know which
systems don't define it, nothing I have running right now at least.

The order of the patches is the inverse of the mail, as I wrote the
first before finishing the second, sorry if that causes any confusion.

What do you think?  Any ideas or points I may have missed?  Suggestions?

Happy hacking!
Miguel
--
[1] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/uselocale.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/duplocale.html
[3] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/newlocale.html
[4] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/functions/freelocale.html