[Bug libstdc++/13631] Problems in messages

2009-06-14 Thread mrsam at courier-mta dot com
--- Comment #11 from mrsam at courier-mta dot com 2009-06-14 14:54 --- The first part of this bug can be solved by using dcgettext(). do_open() needs to save the text domain in the std::messages object, and do_get() needs to use it to invoke dgettext(). The patch appears to be

[Bug libstdc++/13631] Problems in messages

2009-06-14 Thread mrsam at courier-mta dot com
--- Comment #12 from mrsam at courier-mta dot com 2009-06-14 17:14 --- Created an attachment (id=17994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17994&action=view) Untested patch to fix the first issue Here's an untested patch to fix at least the first issue.

[Bug libstdc++/13631] Problems in messages

2009-06-14 Thread mrsam at courier-mta dot com
--- Comment #15 from mrsam at courier-mta dot com 2009-06-14 18:57 --- Although I'm the last person who'd shy away from dirty tricks, when it suits my purposes, I see none here. The catalog name received by open() needs to be stashed away somewhere, and passed as a parameter t

[Bug libstdc++/13631] Problems in messages

2009-06-15 Thread mrsam at courier-mta dot com
--- Comment #16 from mrsam at courier-mta dot com 2009-06-15 11:13 --- After staring at the code for a while, I'm leaning towards thinking that this change does not really change the application ABI, so the soname bump is not needed. As far as I can tell, there are no public membe

[Bug libstdc++/13631] Problems in messages

2009-06-15 Thread mrsam at courier-mta dot com
--- Comment #18 from mrsam at courier-mta dot com 2009-06-15 21:53 --- Yes, the patch does add a new data member to the class. I see that this would fall under item #8 under "prohibited changes", although, as I said, AFAIK it won't actually break binary compatibilit

[Bug libstdc++/13631] Problems in messages

2009-06-15 Thread mrsam at courier-mta dot com
--- Comment #23 from mrsam at courier-mta dot com 2009-06-16 03:51 --- Created an attachment (id=18004) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18004&action=view) Revised patch Well, this is approximately what I have in mind. Aside from the formatting style, whic

[Bug libstdc++/13631] Problems in messages

2009-06-16 Thread mrsam at courier-mta dot com
--- Comment #25 from mrsam at courier-mta dot com 2009-06-16 11:07 --- Yes, but, unfortunately, I just realized that this only partially fixes the original issue. This would fix the use case where different parts of the application use different locales, and different instances of std

[Bug c++/34696] New: Overloaded template losing type in invoking a superclass method?

2008-01-06 Thread mrsam at courier-mta dot com
Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrsam at courier-mta dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34696

[Bug libstdc++/13631] Problems in messages

2009-06-16 Thread mrsam at courier-mta dot com
--- Comment #27 from mrsam at courier-mta dot com 2009-06-16 21:54 --- I thought of that, but using a vector will not be thread safe. Although I don't believe that the C++ standard requires thread safety for std::messages, applications will definitely expect thread safety here

[Bug libstdc++/13631] Problems in messages

2009-06-18 Thread mrsam at courier-mta dot com
--- Comment #29 from mrsam at courier-mta dot com 2009-06-19 00:47 --- Created an attachment (id=18022) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18022&action=view) Revised revised patch Here's a whack at actually keeping track of different message catalogs. It c