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