using xlocale to implement std::locale class

[Sam Varshavchik]

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;
}


			

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20110506/100af84f/attachment.sig>