This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using xlocale to implement std::locale class

On 05/09/2011 03:55 PM, Sam Varshavchik wrote:
Paolo Carlini writes:

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("gcc", l));

std::cout << msgcat.get(libc, 0, 0, "\"%s\" is not a valid option to the preprocessor")
<< std::endl;"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 !


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]