DR 13631 patch

[Paolo Carlini]

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?
> - 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.
> - 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.

Paolo.