Re: using xlocale to implement std::locale class

[Paolo Carlini <paolo dot carlini at oracle dot com>]

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.