This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/8539: 22_locale
- From: bkoz at gcc dot gnu dot org
- To: dmitry_belous at ua dot fm, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Date: 14 Nov 2002 18:14:54 -0000
- Subject: Re: libstdc++/8539: 22_locale
- Reply-to: bkoz at gcc dot gnu dot org, dmitry_belous at ua dot fm, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: 22_locale
State-Changed-From-To: closed->feedback
State-Changed-By: bkoz
State-Changed-When: Thu Nov 14 10:14:54 2002
State-Changed-Why:
Paolo, a bit of a clarification.
This issue cannot be reproduced on linux, because it uses the gnu locale model that actually implements named locales. For other configurations, namely cygwin, a different configuration is used, ie the generic config. In this configuration, the bug can be reproduced.
The generic config does not attempt to create accurate named locales and instead all "named locales" use the "C" locale. Because of this, attempts to create fake or non-existent named locales (as in the test case) will "succeed" in that they are created (but contain only "C" locale info.)
This is a QOI issue, but not a bug. The standard allows implementation-defined behavior on this point: the generic locale model's defined behavior is to allow it.
Funding to implement a more useful generic locale model is not forthcoming. Patches to implement it have also not been forthcoming. When either of these change, the generic locale model will be more interesting.
-benjamin
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8539