Re: using xlocale to implement std::locale class

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 5 May 2011 01:19, Takeshi Kobayakawa wrote:
> I understand the thread safety issues with locale, now.
> However, aren't they handled with xlocale's newlocale, duplocale,
> freelocale, uselocale API?

Yes, but the darwin model is based on another model which was written
before those interfaces exited.  At that time only glibc supported an
API like that.

The reason they're not used is not because they don't work, but
because they are new, and noone has rewritten the code to use them.

Someone who cares about darwin needs to contribute code if they want changes ...

> I'm trying myself to compile on darwin by copying the contents of
> config/locale/gnu to config/locale/darwin directory and trying to fix which
> cannot be compiled. (I know how configure script works, and regenerated the
> script to surely handle my new code.)
>
> Now I have a problem:
> __c_locale is not compatible with locale_t which is defined in xlocale.
> The def. of __c_locale: ? typedef int* ?__c_locale; (in c++locale.h)

That is the definition for the "generic" model which can't rely on
locale_t being defined.

If you look at the gnu/c_locale.h file you will see that __c_locale is
a typedef for __locale_t, which is the same as locale_t.

> The def. of locale_t ?: typedef struct _xlocale * locale_t; (in
> /usr/include/xlocale.h on darwin)

If you want to make darwin use the new xlocale API then __c_locale
should be the same as locale_t.

> For example, the call for wctype_l won't compile because 2nd argument is
> called with __c_locale typed variable ctype::_M_c_locale_ctype.
> (Since the difference is just the type of pointers, reinterpret_cast will
> conceal the problem. But just I don't want such a workaround.)

A reinterpret_cast between incompatible types is not a good idea.

> I see at least two possible solutions.
> 1. make ctype::_M_clocale_ctype a type of locale_t
> 2. make __c_locale type the same as locale_t
> Which is the better?, or any other solutions?
> (I don't know the history of how locale_t or xlocale is constructed, so I
> can't imagine redefining them breaks other things to what extent.)

I think 2 is the right option.

If that isn't possible without changing the ABI of the darwin locale
model then you could create a new model. Maybe based on POSIX.2008 if
it can be defined only in terms of the latest POSIX API, or but let's
call it darwin2.  That would allow you to leave the existing darwin
model and create a totally new (incompatible) one enabled by
--enable-clocale=darwin2