Re: using xlocale to implement std::locale class

[Sam Varshavchik <mrsam at courier-mta dot com>]

FranÃois Dumont writes:

> On 05/06/2011 09:25 PM, Sam Varshavchik wrote:
> > Paolo Carlini writes:
> >
> > > On 05/05/2011 10:52 PM, Paolo Carlini wrote:
> > > > Indeed, it would be nice if Sam could test the patch. I can also look into  
> > > > it tomorrow or over the next days anyway.
> > > >
> > > > Francois, what did you mean exactly in the audit trail by: "For info a  
> > > > regression has been reported using this patch so it is surely not yet  
> > > > ready."? On which test? In which conditions?
> > > In the meanwhile I re-diffed the patch vs current mainline and attached it  
> > > to the PR.
> > >
> > > On GNU-Linux I'm seeing this fail:
> > >
> > > named_equivalence.exe: .../libstdc++-v3/testsuite/ 
> > > 22_locale/messages_byname/named_equivalence.cc:67: void test01(): Assertion  
> > > `s03 == "bitte"' failed.
> > > FAIL: 22_locale/messages_byname/named_equivalence.cc execution test
> > >
> > > no idea at moment whether it's something serious or a small tweak on top of  
> > > it would be enough. Maybe Sam can help...
> >
> > I don't think I'm running the testsuite correctly. I've executing make check  
> > RUNTESTFLAGS='conformance.exp=messages*'. I do not get this failure even  
> > though I have Francois' patch applied, and my out of tree test for the  
> > original bug, that I'm linking directly against the built libstdc++.a passes  
> > the test for the fix. Yet, make check seems to work without applying the fix  
> > to messages_byname/named_equivalence.cc. But if I stick VERIFY(0 == 1) in  
> > there, it fails.
> >
> > In any case, I think the existing regression tests should be trivially  
> > modifiable to test Francois' patch too. All you need is to another call to  
> > open() for another domain ("gcc" should be good enough), after one of the  
> > existing calls. Without the messages patch, this should make the regression  
> > test break. With the patch, it will still work.
> Thanks Sam for the tips to work on my message facet issue, I will try with  
> strace.
>
> Here is attached the test I had written to challenge my patch using okular  
> and pulseaudio catalogs. It should go into testsuite/ 
> 22_locale/messages/members/char.

Pulseaudio may not necessarily be installed on the machine that builds gcc,  
so this test would fail.

After thinking about it, I think it's possible to devise a regression test  
for this bug using only the libstdc++ catalog.

Open the libstdc++ catalog, and get any string. The de catalog seems to have  
a lot of localized strings.

Open another catalog, any will do, like "libc". Then go back and get the  
same string from the libstdc++ catalog, and check that it's the same string.

I just tested the following, with and without the messages patch. With the  
patch, both strings are the same. Without the patch, the second one is not  
localized.

	std::locale l("de_DE.utf-8");

	typedef std::messages<char> messages;

	const messages &msgcat=std::use_facet<messages>(l);

	messages::catalog libc(msgcat.open("gcc", l));

	std::cout << msgcat.get(libc, 0, 0, "\"%s\" is not a valid option to the preprocessor")
		  << std::endl;

	msgcat.open("libc", l);

	std::cout << msgcat.get(libc, 0, 0, "\"%s\" is not a valid option to the preprocessor")
		  << std::endl;

	return 0;
}

Attachment: pgp00000.pgp
Description: PGP signature