using xlocale to implement std::locale class

François Dumont francois.cppdevs@free.fr
Mon May 9 19:44:00 GMT 2011


On 05/09/2011 03:55 PM, Sam Varshavchik wrote:
> 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.
I will have a try.
>
>> 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.
Very good analysis, indeed there is a minor ABI breaking change. I leave 
official maintainers pronounce the sentence !

Bests



More information about the Libstdc++ mailing list