http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-31
10:05:35 UTC ---
In fact, ext/vstring seems *already* Ok. The reason being that before checking
whether we can work in place we check whether a reallocation is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-11
16:01:28 UTC ---
In my opinion, this isn't really fixable in a generic and decently neat way in
the current implementation, that is in std::string. I still mean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-11
16:03:23 UTC ---
PS: for 4.9, I think we essentially agree that we want to roll in anyway
__versa_string, break the ABI, etc. We also exchanged some ideas about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-11
18:58:53 UTC ---
Agreed. I don't think we'll ever fix this in the current std::string code TBH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-31
16:52:16 UTC ---
Yes it does. However considering that nobody noticed that for 10 years and that
the std::string implementation is near its end of life anyway (as I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #14 from Michael Haubenwallner michael.haubenwallner at salomon
dot at 2012-08-30 07:33:16 UTC ---
Indeed, the old buffer is freed before being copied.
Yep, this isn't a regression. In fact, with 4.4.3 it was the /empty string/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7/4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2012-08-29 10:50:22 UTC ---
(In reply to comment #0)
Extending the testcase shows even more bad behavior in 4.4.3 and earlier:
#include string
#include cassert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
14:15:58 UTC ---
Jon, didn't we somehow discuss this issue already, in a slightly different form
(the issue of course was less evident pre that fix)? Thus, if I remember
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
14:47:28 UTC ---
Nope, I checked and _M_disjunct seems already Ok. The issue is actually with
the logic in assign when _M_disjunct is false: it assumes we are simply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
15:13:57 UTC ---
Thus, I guess the right thing to do is sort-of the other way around of what I
was thinking: change _M_disjunct in such a way that when the destination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #8 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2012-08-29 15:20:50 UTC ---
Actually, valgrind does show an Invalid write of size 1 for this testcase,
unrelated to the default string at all:
{
std::string s1 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
15:28:45 UTC ---
Ok, I see. The problem is that when the source is inside the destination, we
may be copying one more char, the final '\0', than the current size and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
15:32:29 UTC ---
Note that the last snippet definitely caused problems even before the recent
changes. Can't be a regression. Given the current status of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
16:20:43 UTC ---
I'm sorry, you are right - it's been a while since the last time I looked into
this code - going that way of the conditional is Ok, because the memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
16:53:02 UTC ---
Nope, unfortunately I remembered correctly: if we call _M_replace_safe for
these cases the new chars are copied at the very end. At that point, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-29
23:21:25 UTC ---
In fact, considering this issue a regression seems a bit of an over stretch to
me: the empty rep case used to work essentially be chance, it's just a
20 matches
Mail list logo
