using xlocale to implement std::locale class

[Sam Varshavchik]

Paolo Carlini writes:

> Hi,
>> Pulseaudio may not necessarily be installed on the machine that builds gcc,  
>> so this test would fail.
> I agree this is a concern. The new test should never spuriously fail. It  
> would be ok to add checks and skips parts of it in case something is not  
> available on the machine.
>> 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;
>> }
> Ok, thus this sketch of a safer testcase still needs some work, actually  
> comparing in VERIFY the strings and what else. Isn't ready yet for the  
> actual libstdc++-v3 testsuite. Please let me know if you want to do it or I  
> should take care of that.

I don't think I know how to implement the test case, perhaps François.

> Before proceeding with the patch, anyway, I'd like to be reassured about its  
> binary compatibility, not just in terms of exported symbols, but in the  
> wider runtime sense: what happens if an user binary built with the pre-patch  
> headers and minimally using the sane existing bits of messages is linked vs  
> the post-patch *.so? Are there any risks of regressions in the runtime  
> behavior?

I thought about this all weekend. There might be a regression in a very  
marginal situation where application code itself subclasses std::messages.  
That's going to break.

The only part of the patch that touches the visible header file removes the  
definition of the virtual do_open() method. Even though any existing code  
would still have the original version of do_open() compiled in from the  
header, do_open() should ordinarily be invoked through the virtual function  
pointer, and as long as the app instantiates the facet through the library,  
the std::messages object would get instantiated in the library and should  
have the virtual method use the reimplemented do_open() in the library.

Existing runtime code that, for some reason, subclasses std::messages  
itself, would likely continue to use the previous version of do_open() that  
got compiled into the runtime, and calls to get() would invoke the new  
do_get() from the library. Without a valid catalog handle, do_get() would  
not be able to localize the string.

Also, existing runtime code that does not use message catalogs properly,  
will not work with the patch, like that messages_byname test case.

Existing runtime code that uses message catalogs properly, that does not  
subclass std::messages, and and works within the confines of the existing  
incorrect implementation, should continue to work. I do not believe that the  
old definition of do_open() that was compiled into the runtime code, would  
be used.

Additional factor here is that I don't think that std::messages, given the  
problems with the current implementation, has much footprint. It can't  
possibly be used in anything that's implemented as a shared library, given  
the fact as soon as a shared library tries to localize messages from its own  
domain, this will immediately break anything that uses the shared library  
and uses its own domain. Application code would likely just to use  
std::messages as is, and is unlikely to open multiple domains. As long as  
the runtime uses the catalog handle properly, there would not be a  
regression.
-------------- 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/20110509/bbbfa2a1/attachment.sig>