Re: one idea for next GSoC: libstdc++ locale support based on POSIX 2008 duplocale/uselocale, etc.

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Nov 25, 2013 at 04:24:35PM +0100, Václav Zeman wrote:
> >> What I am proposing is that somebody takes the pure POSIX 2008 API and
> >> implements `std::locale` on top of that.
> >
> > This would be helpful for non-GNU platforms, but would not add any
> > functionality for glibc-based targets, which already have a fully
> > functional <locale> implementation using the GNU-specific features.
> 
> True. That is why I am proposing this as a GSoC task so that non-GNU
> platforms like said FreeBSD and Darwin have decent C++ locale support
> based on POSIX 2008 API.

Isn't that not enough work for GSoC?  I mean, this is an 1-2 hours
coding task plus testing, say abstract the fact whether uselocale/etc.
APIs are available into say some constexpr bool and wrap all the APIs
into some wrapper functions in some special namespace or class, whatever
the libstdc++-v3 maintainers prefer.  Then just use the constexpr bool
instead of the current
#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
preprocessor tests and use the wrappers.

Even glibc 2.3 had both the __uselocale etc. APIs and uselocale, the reason
for using __uselocale is that when uselocale was just a GNU extension, then
say a valid ISO C++98 program could define ::uselocale function and do something
completely different there.  So, if libstdc++ then calls uselocale, it could
crash or misbehave.  So, if __uselocale (which is in implementation
namespace) is available, we certainly want to prefer that over uselocale.

	Jakub