Re: generic locale

[Benjamin Kosnik <bkoz at redhat dot com>]

Sorry I'm so late at responding.

>Here are the choices I would like user input on:
>(b) At least throw an exception in generic for all user instantiations
>    of locale() objects unless they map to the "C" (or ""?) locale.
>    This, at least, better matches reality.  (Optionally, modify all
>    22_locale test case per Martin's idea and/or catch the
>    generic-doesn't-handle-non-C-locale exception and accept that as
>    an OK run-time termination.)

Probably a good idea.

I believe there are already tests for all facets that exercise the "C"
locale. That was one of the points of the 22_locale testsuite re-do.

In retrospect, the non-"C" bits should have probably been written with
abstracted locale data, as Martin indicated, instead of taking the easy
way out and using explicitly specified named locales with specific
characteristics from a known good implementation.

As Nathan would say: I leave this exercise for somebody else.

>(c) make generic work for single-threaded programs no matter how slow
>    it is; use my system's libc dammit (note: the status quo is already
>    broken w.r.t. threading since any unguarded call to setlocale()
>    are unsafe and we would have no idea what users might do outside
>    the library code)
>
>(d) make generic work for multi-threaded programs (as long as all IO
>    is C++-style, see note in c) no matter how slow it is; use my
>    system's libc dammit
>
>(e) make generic work for multi-threaded programs (a small race would
>    remain against user programs with threads of control that called
>    setlocale() directly but protect internal library use); use C89
>    locale calls only to fetch "struct lconv" from OS but otherwise
>    assume that IO conversions are now disconnected from libc

Really, I think your initial reaction was correct: try to use the
existing iee-2001.1003 codepath for BSD. It needs work, but I think this
API is better than the "C" one. I suspect that the lock can be put into
the __c_locale data type.

I believe this should be possible.

>(f) do whatever you want Loren but put it in 'enhanced-generic' which
>    is cloned off generic to start

This is certainly to be encouraged as the starting off point for people
who wish to add platform-specific implementations.

>(z) lobby libc maintainers everywhere to add MT-safe API points that
>    match up with glibc

I believe this API will be presented to POSIX for future inclusion.

best,
benjamin