[RFC] libstdc++/7811 vs libstdc++/7222

[Paolo Carlini]

Hi Benjamin, thanks for your feedback

Benjamin Kosnik wrote:

>>What happens with 3.2 and current mainline is that the environment is 
>>not taken into account and loc is *always* "C".
>>The regression was introduced with the checkin for libstdc++/7222 (by 
>>the way, to date I still cannot reproduce it the problem reported therein):
>>    
>>
>Yep. I figured this was the issue.
>
>This was checked in as part of the PR:
>
>// libstdc++/7222
>void test02()
>{
>  bool test = true;
>  std::locale loc_c1("C");
>  std::locale loc_c2 ("C");
>  
>  std::locale loc_1("");
>  std::locale loc_2("");
>
>  VERIFY( loc_c1 == loc_c2 );
>  VERIFY( loc_1 == loc_2 );
>}
>
>I'd been able to reproduce the fail with this testcase. Is that not the
>case for you?
>
Actually it is'nt: at the time I remarked that in the audit trail, and 
still cannot reproduce it today. Dunno why...
Ideas?

>Note that for the part of locale.cc you are patching, it is known that
>__s == "". 
>
Indeed, thanks.

>>However, I'm not sure about the corresponding MT-aware glibc2.3 solution 
>>using __uselocale.
>>    
>>
>Maybe the following, where __s == "". Basically, this is just a question
>of how to get read-only info from the current locale using __uselocale.
>
>      __c_locale __env;
>      _S_create_c_locale(__env, __s);
>      __c_locale __old = __uselocale(__env);
>
>     // do stuff
>
>      __uselocale(__old);
>      _S_destroy_c_locale(__env);
>
Thanks, right now I'm still not much into the new MT-aware contructs.

I'm going to prepare a complete fix implementing your suggestion.

Ciao, Paolo.