| Message ID | 20130211153359.74f27ab4@octopus |
|---|---|
| State | New |
| Headers | show |
Hi, On 02/11/2013 04:33 PM, Julian Brown wrote: > Hi, > > It seems that glibc 2.17 changes the abbreviated names of weekdays for > "ru_RU" locales by removing an extraneous ".", as described in: > > http://sourceware.org/bugzilla/show_bug.cgi?id=10873 > > An earlier patch (circa glibc 2.14) changed (IIUC!) archaic/unusual > three-letter abbreviations to more-common two-letter abbreviations, but > included dots after each weekday name, which was apparently still wrong. > But, the two tests of this feature in the libstdc++ testsuite expect > those dots to be present, so they fail. > > So, the attached patch simply removes the expectation that dots are > present in the abbreviated names from the libstdc++ tests in question, > if the glibc version in use is recent enough. > > The tests pass (with a current gcc, trunk eglibc) with the attached > patch, and fail (for me) without it (cross-testing to ARM Linux, for > no particular reason). OK to apply? I think it's Ok, yes. Thanks. However, I would appreciate if somebody with a glibc 2.17 system at hand could double check. Maybe HJ? Thanks, Paolo.
On Mon, Feb 11, 2013 at 9:18 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi, > > > On 02/11/2013 04:33 PM, Julian Brown wrote: >> >> Hi, >> >> It seems that glibc 2.17 changes the abbreviated names of weekdays for >> "ru_RU" locales by removing an extraneous ".", as described in: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=10873 >> >> An earlier patch (circa glibc 2.14) changed (IIUC!) archaic/unusual >> three-letter abbreviations to more-common two-letter abbreviations, but >> included dots after each weekday name, which was apparently still wrong. >> But, the two tests of this feature in the libstdc++ testsuite expect >> those dots to be present, so they fail. >> >> So, the attached patch simply removes the expectation that dots are >> present in the abbreviated names from the libstdc++ tests in question, >> if the glibc version in use is recent enough. >> >> The tests pass (with a current gcc, trunk eglibc) with the attached >> patch, and fail (for me) without it (cross-testing to ARM Linux, for >> no particular reason). OK to apply? > > I think it's Ok, yes. Thanks. However, I would appreciate if somebody with a > glibc 2.17 system at hand could double check. Maybe HJ? > I am not familiar with locale. CC to glibc mailing list.
On 02/11/2013 12:28 PM, H.J. Lu wrote: > On Mon, Feb 11, 2013 at 9:18 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: >> On 02/11/2013 04:33 PM, Julian Brown wrote: >>> >>> Hi, >>> >>> It seems that glibc 2.17 changes the abbreviated names of weekdays for >>> "ru_RU" locales by removing an extraneous ".", as described in: >>> >>> http://sourceware.org/bugzilla/show_bug.cgi?id=10873 >>> >>> An earlier patch (circa glibc 2.14) changed (IIUC!) archaic/unusual >>> three-letter abbreviations to more-common two-letter abbreviations, but >>> included dots after each weekday name, which was apparently still wrong. >>> But, the two tests of this feature in the libstdc++ testsuite expect >>> those dots to be present, so they fail. >>> >>> So, the attached patch simply removes the expectation that dots are >>> present in the abbreviated names from the libstdc++ tests in question, >>> if the glibc version in use is recent enough. >>> >>> The tests pass (with a current gcc, trunk eglibc) with the attached >>> patch, and fail (for me) without it (cross-testing to ARM Linux, for >>> no particular reason). OK to apply? >> >> I think it's Ok, yes. Thanks. However, I would appreciate if somebody with a >> glibc 2.17 system at hand could double check. Maybe HJ? >> > > I am not familiar with locale. CC to glibc mailing list. Paolo, glibc 2.17 and eglibc 2.17 are so close that it should be fine to test just one. I'd think the change should be fine for libstdc++. Upstream will be working to reduce the differences between eglibc and glibc so eventually these reports will just say "glibc" in their testing notes. Does that make sense? Cheers, Carlos.
On 11 February 2013 17:18, Paolo Carlini wrote: > > I think it's Ok, yes. Thanks. However, I would appreciate if somebody with a > glibc 2.17 system at hand could double check. Maybe HJ? Although I'm sure Carlos is right that they're close enough to not need checking, I've got a Rawhide setup with glibc 2.17 so I can test it, just to be sure.
On 11 February 2013 19:15, Jonathan Wakely wrote: > On 11 February 2013 17:18, Paolo Carlini wrote: >> >> I think it's Ok, yes. Thanks. However, I would appreciate if somebody with a >> glibc 2.17 system at hand could double check. Maybe HJ? > > Although I'm sure Carlos is right that they're close enough to not > need checking, I've got a Rawhide setup with glibc 2.17 so I can test > it, just to be sure. Julian's patch does indeed fix the test failures on glibc 2.17, so is OK to commit. Thanks!
Index: libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-1.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-1.cc (revision 195939) +++ libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-1.cc (working copy) @@ -50,7 +50,11 @@ void test01() // ios_base::iostate&, tm*) const #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14) +# if __GLIBC__ > 2 || __GLIBC_MINOR__ >= 17 + iss.str("\xbf\xdd"); +# else iss.str("\xbf\xdd\x2e"); +# endif #else iss.str("\xbf\xdd\xd4"); #endif @@ -72,7 +76,11 @@ void test01() VERIFY( errorstate == ios_base::eofbit ); #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14) +# if __GLIBC__ > 2 || __GLIBC_MINOR__ >= 17 + iss.str("\xbf\xdd\xd5\xd4\xd5\xdb\xec\xdd\xd8\xda"); +# else iss.str("\xbf\xdd\x2e\xd5\xd4\xd5\xdb\xec\xdd\xd8\xda"); +# endif #else iss.str("\xbf\xdd\xd4\xd5\xd4\xd5\xdb\xec\xdd\xd8\xda"); #endif Index: libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-2.cc =================================================================== --- libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-2.cc (revision 195939) +++ libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-2.cc (working copy) @@ -51,6 +51,15 @@ void test01() // ios_base::iostate&, tm*) const #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14) +# if __GLIBC__ > 2 || __GLIBC_MINOR__ >= 17 + const char* awdays[7] = { "\u0412\u0441", + "\u041F\u043D", + "\u0412\u0442", + "\u0421\u0440", + "\u0427\u0442", + "\u041F\u0442", + "\u0421\u0431" }; +# else const char* awdays[7] = { "\u0412\u0441\u002E", "\u041F\u043D\u002E", "\u0412\u0442\u002E", @@ -58,6 +67,7 @@ void test01() "\u0427\u0442\u002E", "\u041F\u0442\u002E", "\u0421\u0431\u002E" }; +#endif #else const char* awdays[7] = { "\u0412\u0441\u043A", "\u041F\u043D\u0434",
Hi, It seems that glibc 2.17 changes the abbreviated names of weekdays for "ru_RU" locales by removing an extraneous ".", as described in: http://sourceware.org/bugzilla/show_bug.cgi?id=10873 An earlier patch (circa glibc 2.14) changed (IIUC!) archaic/unusual three-letter abbreviations to more-common two-letter abbreviations, but included dots after each weekday name, which was apparently still wrong. But, the two tests of this feature in the libstdc++ testsuite expect those dots to be present, so they fail. So, the attached patch simply removes the expectation that dots are present in the abbreviated names from the libstdc++ tests in question, if the glibc version in use is recent enough. The tests pass (with a current gcc, trunk eglibc) with the attached patch, and fail (for me) without it (cross-testing to ARM Linux, for no particular reason). OK to apply? Thanks, Julian ChangeLog libstdc++/ * testsuite/22_locale/time_get/get_weekday/char/38081-1.cc (test01): Don't expect dots after abbreviated weekday names for ru_RU for glibc versions >= 2.17. * testsuite/22_locale/time_get/get_weekday/char/38081-2.cc (test01): Likewise.