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