Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, October 03, 2007 11:21 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: 22.locale.moneypunct test fails on MSVC

Farid Zaripov wrote:
The 22.locale.moneypunct test fails on MSVC (and
ICC/Windows) due to
bug of the CRT or native API.

The following program aborts on assert (tested on all MSVC's on Windows XP 32 and 64 bit). This program fails only for some
locales.
So it fails with locname = "Catalan_Spain.1252"
but succeeds with locname = "Russian_Russia.1251".
Hmm. That makes the LC_MONETARY category pretty much unusable on Windows. We need to open a bug with Microsoft and get this fixed.

  Now I think that it's not a bug of the MSVC. My system locale is
Russian_Russia.1251 (codepage = 1251). When LC_MONETARY
id used, the unicode value of the euro sign is converted into 1251
codepage (using WideCharToMultiByte() API function).
From etc/nls/charmaps/CP1251 (/x88 == -120):
<U20AC>     /x88         EURO SIGN

  And when LC_ALL is used, the unicode value of the euro sign is
converted into 1252 codepage.

From etc/nls/charmaps/CP1252 (/x80 == -128):
<U20AC>     /x80         EURO SIGN

  The std::moneypunct<> facet uses setlocale (LC_ALL, ) when initializes
the facet data, so I think the 22.locale.moneypunct.cpp test should use
setlocale (LC_ALL, ) instead of setlocale (LC_MONETARY, ), or use
setlocale (LC_CTYPE, ) before setlocale (LC_MONETARY, )..

You might very well be right. LC_MONETARY affects the values
of the punctuators but LC_CTYPE determines their multibyte
encoding.

Martin

Reply via email to