using xlocale to implement std::locale class
Paolo Carlini
paolo.carlini@oracle.com
Fri May 6 22:44:00 GMT 2011
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.
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?
Thanks,
Paolo.
More information about the Libstdc++
mailing list