Hi Howard and others,<br><br>I am struggling to get the locale related tests in libc++ working like they should. In attached patch I added a header in the main test directory, defining the locale names for Windows and the rest. I replaced all occurrences of the name in a test's source code with an include to this file and the macro I defined. For every platform != windows, this should come down to the same thing. for Windows, I could not use UTF-8 locales, as they are unsupported and always return 0 when trying to setlocale or newlocale (_create_locale). The patch also fixes a bad #endif placement (if I'm not mistaken) in localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp<br>
<br>The patch fixed exceptions being thrown because of bad locale names, but not the test's failures. To compare, I used this test code (freely adapted to resemble the true test):<br><a href="http://stackoverflow.com/questions/7627445/stdget-time-and-other-locale-functionality-not-working-correctly-on-windows">http://stackoverflow.com/questions/7627445/stdget-time-and-other-locale-functionality-not-working-correctly-on-windows</a><br>
<br>and tried to run the test on MSVC10 and its STL. It compiles, but the asserts fail, as all values are 0. GCC 4.6.1+stdlibc++ isn't capable of compiling this code: it's missing the function std::get_time for some reason. These kinds of unexplained failures are present across the board. Their causes seem either unrelated or hidden in the same place in locale-code not yet fixed for Windows. The fact remains that MSVC10, which has the above function, fails the test, which makes me think the input character buffer needs to be in different format.<br>
<br>I plan on adding floating point number macros (which create a string with the expected format from a base and exponent) to this header as well:<br>FLOAT_MACRO(1234.1234, -56)<br>would become<br>"1234.1234" "e" "-" "56"<br>
or<br>"1234.1234" "e" "-" "0" "56"<br>(implicitely letting the compiler concatenate the string literals) or whatever depending on what it is on that platform. I think this will solve the locale related numerics failures.<br>
<br>The attached patch got rid of only two test failures (438 to 436), but as I said, at least the locales are being constructed properly, and the remaining failures are due to something else now.<br><br>Ruben<br>