Anton Pevtsov wrote:
The jira issue created:
http://issues.apache.org/jira/browse/STDCXX-170
Thanks!
FWIW, as a future reference, it's good practice to make the expected
effects of a test case explicit by asserting the relevant postconditions
(i.e., replace the output statement with or add below it the statement
assert (test == s);). That way it's crystal clear to whoever decides
to reproduce the issue or verify a fix for it in the future whether
it still exists or not.
Martin
Thanks,
Anton Pevtsov
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 12:15
To: [email protected]
Subject: Re: basic_string::insert (iterator p, InputIterator first,
InputIterator last) on Linux, gcc-4.0.2
Anton Pevtsov wrote:
I updated the test for the replace method and reproduced the problem
discovered in the insert's test.
Great, thanks for the detective work! Could you please open a new issue
in Jira for this bug and add a link to this thread to it (as soon as it
shows up in the archive)?
Martin
This test fails on Widows, MSVC 7.1, build 11d and on SuSe Linux 9.1
gcc
4.0.2:
#include <iostream>
#include <string>
static const char* test = "babc";
int main (void)
{
std::string s ("abc");
s.replace (s.begin (), s.begin (), s.begin () + 1, s.begin () +
2);
std::cout << "Expected " << test << " and got " << s << '\n';
return 0;
}
The output is "Expected babc and got aabc".
I investigated the problem and found that cause is in the
__rw_replace_aux function implementation in string.cc, line 566. There
is the following code (line 643):
...
// Current reference has enough room.
if (__rem)
traits_type::move(__s._C_data+__pos+__n2,
__s._C_data+__pos+__n,
__rem);
for (__d = 0; __d < (size_type)__n2; __d++)
traits_type::assign (*(__s._C_data+__pos+__d),
*__first2++);
traits_type::assign
(__s._C_data[__s._C_pref()->_C_size._C_size
= __len], value_type()); ...
For the exmaple above we have __pos = 0, __n2 = 1, __n = 0, __rem = 3,
and __s._C_data points to the begin of the "abc" string. Note, that
the iterator __first2 points to the same string, to symbol 'b'.
As first step this code moves the string and this operation results in
"aabc". But the __first2 doesn't change - and now it points to the
same place, but there is the symbol 'a' !
Second step just copies the second 'a' to first 'a' in the string and
third step places zero at the end of string. So, the result of the
replace call differs from the expected one.
Thanks,
Anton Pevtsov
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 16:22
To: [email protected]
Subject: Re: basic_string::insert (iterator p, InputIterator first,
InputIterator last) on Linux, gcc-4.0.2
Anton Pevtsov wrote:
[...]
It works fine on MSVC. The test fails on SuSe Linux 9.1 with gcc 4.0.2
only. And it looks like this is a problem on my local machine - Liviu
couldn't reproduce it. When I finish the replace test I'll clean up
all on my Linux machine and build the library from scratch again.
It might also be a problem with the compiler. I don't think I'll be
able to look into it until I get back. Working remotely from where I
am (Berlin, Germany) is excruciatingly slow and I cannot reproduce it
on my laptop. Try stepping through the code in the debugger to see if
it behaves correctly.
Martin
