This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: using xlocale to implement std::locale class
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