[v3] libstdc++/7811

[Jakub Jelinek]

On Fri, Sep 06, 2002 at 12:20:26AM +0200, Paolo Carlini wrote:
> >>to fix this regression from 3.1.1 I have committed the below to mainline 
> >>and 3.2.
> >>Tested i686-pc-linux-gnu, approved by Benjamin Kosnik (and myself ;)
> >>    
> >>
> >This looks wrong. What about if you have
> >LC_MESSAGES=cs_CZ LC_CTYPE=cs_CZ LANG=en_US
> >or other mix of env variables? setlocale(LC_ALL, ""); in such case would
> >build a composite name, though current libstdc++-v3 will not.
> >
> Hi Jakub. I think that nothing in the C++ mandates to match in detail 
> the setlocale(LC_ALL, "") behaviour. I see that something like what you 
> are proposing would improve the QoI but I don't know how to actually 
> implement it, at the moment. Consider that...
> 
> >For #ifndef _GLIBCPP_C_LOCALE_GNU you should do:
> >old = strdup(setlocale(LC_ALL, NULL));
> >ret = strdup(setlocale(LC_ALL, ""));
> >setlocale(LC_ALL, old);
> >free(old);
> >or some such, for _GLIBCPP_C_LOCALE_GNU maybe "" should be passed directly
> >to _Impl constructor...
> >
> ... as Roland McGrath explained to me privately setlocale(LC_ALL, "") 
> *cannot* be used in a MT environment.

That's true, but without uselocale you basically have no other option.
Even when you have some _l routines, lots of others are still missing.

So IMHO at least with glibc 2.3+ we should DTRT (provided that we allow
libstdc++-v3 to use __names[] members of struct __locale_struct), which
is pass "" as locale name down to _Impl down to _S_create_locale in that
case and if we really need accurate _M_names, set them
from __cloc->__names[x].

	Jakub