This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
[RFC] libstdc++/7811 vs libstdc++/7222
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: libstdc++ at gcc dot gnu dot org
- Cc: bkoz <bkoz at redhat dot com>
- Date: Wed, 04 Sep 2002 17:25:57 +0200
- Subject: [RFC] libstdc++/7811 vs libstdc++/7222
Hi all,
I'm currently investigating this regression from 3.1.1. This is the
testcase:
#include <locale>
#include <iostream>
int main(){
using namespace std;
locale loc("");
cout << loc.name() << endl;
}
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):
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/locale.cc,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- gcc/libstdc++-v3/src/locale.cc 2002/04/18 23:47:48 1.60
+++ gcc/libstdc++-v3/src/locale.cc 2002/07/25 06:42:00 1.61
@@ -202,7 +202,7 @@
if (strcmp(__s, "C") == 0 || strcmp(__s, "POSIX") == 0)
(_M_impl = _S_classic)->_M_add_reference();
else if (strcmp(__s, "") == 0)
- _M_impl = new _Impl(setlocale(LC_ALL, __s), 1);
+ _M_impl = new _Impl(setlocale(LC_ALL, NULL), 1);
else
_M_impl = new _Impl(__s, 1);
}
Now, NULL cannot be correct since by using it the name of the current
locale is returned which, however, is always "C" in the testcase,
irrespective of the environment variables. Neither __s can be correct
since it *sets* the current locale.
I believe that a possible not-MT-aware solution would be the usual pattern
{
char* __old = strdup(setlocale(LC_ALL, NULL));
_M_impl = new _Impl(setlocale(LC_ALL, __s), 1);
setlocale(LC_ALL, __old);
free(__old);
}
Useful to extract the name of the locale set in the environment without
actually changing it for the running program.
However, I'm not sure about the corresponding MT-aware glibc2.3 solution
using __uselocale.
Suggestions?
Thanks,
Paolo.