https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109737
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109737
Bug ID: 109737
Summary: [13/14] Hitting unreachable code when using
std::string::assign with iterators
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jonathan Wakely changed:
What|Removed |Added
Blocks||24882
Target Milestone|4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Richard Biener changed:
What|Removed |Added
Target Milestone|4.7.4 |4.8.4
--- Comment #24 from Richard Bien
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #23 from Jonathan Wakely ---
Yes, definitely. It should get fixed automatically by switching to the new
std::string impl.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #22 from Jakub Jelinek ---
So 5.0 material, given that we are not going to change std::string in 4.9?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.6.4 |4.7.4
--- Comment #21 from Jaku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #20 from Paolo Carlini 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 needed, thus in
all the cases at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #19 from Jonathan Wakely 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
--- Comment #18 from Paolo Carlini 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 that
with Jason, off lists.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #17 from Paolo Carlini 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 to fix it in
__versa_string for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.6.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #15 from Paolo Carlini 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 said, in
the new one the fix is str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #14 from Michael Haubenwallner 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/
having the size of 1 in the comment#0 testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #13 from Paolo Carlini 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 very
special case (... of a very
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #12 from Paolo Carlini 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
destination string is already reall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #11 from Paolo Carlini 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
corresponding to the source (whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #10 from Paolo Carlini 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 implementation
I'm not sure if is worth fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #9 from Paolo Carlini 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
overflow the allocated memory. We n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #8 from Michael Haubenwallner 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 = "a";
s1.assign(s1.c_str(), 2);
}
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #7 from Paolo Carlini 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 is the
empty rep it always return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #6 from Paolo Carlini 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
overwriting things and no memory al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #5 from Paolo Carlini 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
correctly what I was thinking a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #4 from Michael Haubenwallner 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
#include
int main()
{
std::string s1, s2;
s1.assign(s2.c
]
|std::string::append() fails |std::string::assign() fails
|to update length|to update length
--- Comment #3 from Jonathan Wakely 2012-08-29
07:35:36 UTC ---
For some reason my fingers keep typing append when I mean assign.
s/append/assign/g
Date: Tue, 28 Aug 2012 13:56:46 +0100
From: Jonathan Wakely
To: Richard Kojedzinszky
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: std::string::assign
Re: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg01843.html
Hi, the gcc-bugs mailing list is for automated mails from our bug
database, http://gcc.gn
Re: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg01843.html
Hi, the gcc-bugs mailing list is for automated mails from our bug
database, http://gcc.gnu.org/bugzilla
To ensure a response you should either file a bug in the bugzilla
database to it can be tracked and found by the interested parties, or
Dear All,
I've a strange bug, I've attached a small source which shows my issue.
So, I am trying to assign a string containing an embedded \0 in it. You
will find that in test() I use std::string::assign to do this, but in two
cases the results are different.
Please see the out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #14 from Jonathan Wakely 2011-03-25
09:54:25 UTC ---
(In reply to comment #13)
>
> Sorry for the confusion here Jon. I meant to ask if the specs define what the
> behaviour should be if __s *does not* contain __n elements.
No, it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #13 from Mohsin 2011-03-25 05:48:21
UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Two questions here:
> > >
> > > 1. Is the behaviour undefined for __n < number of elements in __s?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #12 from Jonathan Wakely 2011-03-24
11:27:44 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > Two questions here:
> >
> > 1. Is the behaviour undefined for __n < number of elements in __s?
> >
>
> Oops!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #11 from Mohsin 2011-03-24 10:24:15
UTC ---
(In reply to comment #10)
> Two questions here:
>
> 1. Is the behaviour undefined for __n < number of elements in __s?
>
Oops! I meant for __n > number of elements in __s.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #10 from Mohsin 2011-03-24 10:21:56
UTC ---
Two questions here:
1. Is the behaviour undefined for __n < number of elements in __s?
2. For cases undefined in the specs, do we take steps to ensure robustness? I
still cannot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #9 from Mohsin 2011-03-24 09:52:56
UTC ---
(In reply to comment #7)
> (In reply to comment #4)
> >
> > I don't see any errors being thrown. I am not trying to nit-pick but I've
> > raised this issue because I was affected by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #8 from Mohsin 2011-03-24 09:50:11
UTC ---
(In reply to comment #6)
> Also, GCC 4.1.2 is ancient and not supported here, you should either report
> bugs to the vendor of your version (Red Hat) or refer to a supported version.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #7 from Jonathan Wakely 2011-03-24
09:37:03 UTC ---
(In reply to comment #4)
>
> I don't see any errors being thrown. I am not trying to nit-pick but I've
> raised this issue because I was affected by it and had to spend seve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
--- Comment #6 from Jonathan Wakely 2011-03-24
09:29:28 UTC ---
Also, GCC 4.1.2 is ancient and not supported here, you should either report
bugs to the vendor of your version (Red Hat) or refer to a supported version.
As for being disres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Mohsin changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Mohsin changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Summary: std::string::assign() corrupts std::string static data
when called on emptyString1 using emptyString2.data()
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
46 matches
Mail list logo
