DR 13631 patch

[François Dumont]

On 02/22/2012 12:30 PM, Paolo Carlini wrote:
> Hi,
>> Hi
>>
>>     I would like to fix DR 13631 regarding the impossibility to open 
>> 2 catalogs at the same time with current gnu messages facet 
>> implementation.
> Great!
>> I have adapted the test from Sam Varshavchik posted in bugzilla that 
>> use libc and gnupg catalogs to show the problem. I would like to have 
>> your opinion on 2 points of this patch:
> Just to be clear: does the patch otherwise already work? Without 
> breaking the ABI?

The patch works but as Sam noticed last time we work on this issue even 
my patch do break ABI. I have plan to push it to the ABI breaking 
changes branch.

>> - there are already tests using the libstdc++ catalog that are only 
>> using dg-require-namedlocale to check if it is supported. However I 
>> wonder if there might be platforms with locale support but no 
>> messages implementation or perhaps simply configured to use the 
>> generic implementation. Shouldn't we have something like a 
>> dg-require-message-facet to check that we have a real message facet 
>> implementation ?
> Seems overkilling to me, because I don't think we are supporting such 
> a systems, at the moment. I think dg-require-namedlocale should be ok 
> for now.
>> - Should I introduce a dejagnu macro to check availability of the 
>> libc and gnupg catalogs. Writing this I realize that I could use 
>> libstdc++ in place of one of those catalogs but I would still need to 
>> check for the other
> Given my poor understanding of this area of glibc, I'm not sure to 
> fully understand your question, but I think typical GNU systems are 
> pretty uniform about this.
>
> Maybe we want a new dg-require for messages which for the time being 
> just returns true for say, GNU/Linux systems? Then we can 
> refine/extend the thing.

Good idea.

>> - I use a map to associate int catalogs to gettext domains. Doing so 
>> I need to export a _Rb_tree instantiation which is quite huge, 
>> shouldn't I replace it with a simpler data structure like a sorted 
>> array ?
> Good point. I wonder: is there a way to encapsulate the data structure 
> in the .so in such a way that what is actually exported doesn't reveal 
> the actual internal implementation? Then we could experiment, ie fix 
> the bug, for now with _Rb_tree and then, later on, switch internally 
> the .so to something different, more slick.

I am surprised that it is not already the case, and perhaps it is, I am 
not very comfortable with this. I though that the build would export 
only the messages<char>::do_open, messages<char>::do_close and wchar_t 
versions methods. I was expecting the _Rb_tree implementation detail to 
be fully hidden. Do you know how to achieve this ?


François