https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #35 from Jonathan Wakely ---
Author: redi
Date: Wed Mar 18 16:17:47 2015
New Revision: 221494
URL: https://gcc.gnu.org/viewcvs?rev=221494&root=gcc&view=rev
Log:
PR libstdc++/13631
* config/locale/gnu/messages_members.cc (get_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
François Dumont changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #33 from François Dumont ---
Author: fdumont
Date: Wed Dec 3 19:47:00 2014
New Revision: 218329
URL: https://gcc.gnu.org/viewcvs?rev=218329&root=gcc&view=rev
Log:
2014-12-03 François Dumont
PR libstdc++/13631
* include/b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #32 from Sam Varshavchik 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 uses the message cata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #31 from Paolo Carlini 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 #30 from François Dumont 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 revision 168822. I can't ap
--- 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
compiles, but I
--- 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 #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 unde
--- 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.
--
http
--- 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::m
--- 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 #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, which I can clea
--- 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 #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 #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 versio
--- 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 #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 applic
--- 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 A
--- 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 #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 dgettext(
--- 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 mea
--- 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 #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. I'll try to test
--- 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 straightfo
25 matches
Mail list logo
