https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Wed Mar 18 16:17:47 2015
New Revision: 221494
URL: https://gcc.gnu.org/viewcvs?rev=221494root=gccview=rev
Log:
PR libstdc++/13631
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #33 from François Dumont fdumont at gcc dot gnu.org ---
Author: fdumont
Date: Wed Dec 3 19:47:00 2014
New Revision: 218329
URL: https://gcc.gnu.org/viewcvs?rev=218329root=gccview=rev
Log:
2014-12-03 François Dumont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
François Dumont fdumont at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #31 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-05
21:34:01 UTC ---
Created attachment 24194
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24194
Last patch re-diffed vs current mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #32 from Sam Varshavchik mr...@courier-mta.com 2011-05-05
22:25:50 UTC ---
Created attachment 24196
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24196
Sample test program
Here's a simple test program that I threw together.
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #30 from François Dumont fdumont at gcc dot gnu.org 2011-01-14
21:36:34 UTC ---
Created attachment 22967
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22967
locale message facet patch
Hi
Here is a patch proposition based on
--- 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=18022action=view)
Revised revised patch
Here's a whack at actually keeping track of different message catalogs. It
compiles, but I
--- Comment #24 from paolo dot carlini at oracle dot com 2009-06-16 10:07
---
Interesting... Seems a bit too clever to me, but we'll see. I understand this
kind of patch would fix uses of std::message as installed in a locale, not, so
to speak, stand-alone uses, right? Anyway, could
--- 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
--- Comment #26 from peturrun at gmail dot com 2009-06-16 19:51 ---
Wouldn't it be easy to implement catalogs using a vector? If do_open adds the
catalog name to the vector and returns the index, do_get can get the name back
by using the catalog as the index into the vector.
--
--- 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. The
--- Comment #28 from paolo dot carlini at oracle dot com 2009-06-16 22:03
---
mutexes in general can be used and are used in various places in the library
(but, for the record, we are currently a bit worried by performance issues
having to do with the one for the global locale, we have
--- 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 members of
--- Comment #17 from paolo dot carlini at oracle dot com 2009-06-15 11:36
---
Maybe it's because I didn't really look carefully at the patch: aren't you
adding a new data member to the class? Changing either size or layout of a type
specified in the C++ standard definitely changes the
--- 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 compatibility with existing
--- Comment #19 from paolo dot carlini at oracle dot com 2009-06-15 22:06
---
I think we are definitely going to wait for the next ABI, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #20 from paolo dot carlini at oracle dot com 2009-06-15 22:18
---
One last clarification, maybe necessary because not spelled out (yet) in the
docs: really, when we say *ABI* we mean it in a very wide sense, also including
linking together objects built with different
--- Comment #21 from peturrun at gmail dot com 2009-06-15 23:10 ---
Isn't it possible to add more data to messages without breaking the ABI by
changing the type of one of the existing members?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #22 from paolo dot carlini at oracle dot com 2009-06-15 23:14
---
A patch would help understanding what you exactly mean, at the moment, I'm
skeptical.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- 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=18004action=view)
Revised patch
Well, this is approximately what I have in mind. Aside from the formatting
style, which I can clean
--- 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
--- 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=17994action=view)
Untested patch to fix the first issue
Here's an untested patch to fix at least the first issue. I'll try to test
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-14 17:56
---
We'll never accept an SONAME bump ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #14 from paolo dot carlini at oracle dot com 2009-06-14 18:25
---
That's true, unfortunately, not in the near future, anyway ;) In general,
simple patches in this area managing (*) to not break the ABI would be rather
quickly accepted, however.
(*) When I say managing I
--- 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 to
25 matches
Mail list logo
