This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/7811 vs libstdc++/7222
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.