Hi,

some days ago I submitted a GCC PR (libstdc++/4354) regarding a weird
behaviour of the current GNU libstdc++-v3. My old friend Roberto Bagnara
noticed that the following small program outputs "merge" instead of the
expected "mergesort_ap_variant.pl":

#include <iostream>
#include <string>

using namespace std;

int main() {
  string aux = "../BenchCtiTr/apt/mergesort_ap_variant.pl";
  string::size_type i = aux.rfind("/");
  if (i != string::npos)
    aux.assign(aux, i+1, string::npos);
  cout << aux.c_str() << endl;
}

We both believe that this is a regression wrt libstdc++-v2 but in fact I
haven't been able to find in the ISO standard a discussion of such
topic, namely what exactly basic_string member functions (replace comes
also to mind) are supposed to do when *this is the same string appearing
in the function call and, depending on the actual paramters/iterators,
one is potentially at risk of clobbering the source data during the copy
itself.

Indeed, if one bother to test the behaviour of some popular stdlib
implementations (e.g., STLPort/SGI, Metrowerks, Dinkumware, old
Dinkumware in VC++, Borland) they show embarassingly different
behaviours for specific values of the parameters, as soon as the ranges
involved begin to overlap. Is there any undefined behaviour lurking
here?

Thanks for your attention,
Paolo Carlini.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Paolo Carlini" <pcarlini@unitus.it> wrote in message news:3BB210FC.F5B63C42@unitus.it...

> We both believe that this is a regression wrt libstdc++-v2 but in fact I
> haven't been able to find in the ISO standard a discussion of such
> topic, namely what exactly basic_string member functions (replace comes
> also to mind) are supposed to do when *this is the same string appearing
> in the function call and, depending on the actual paramters/iterators,
> one is potentially at risk of clobbering the source data during the copy
> itself.
>
> Indeed, if one bother to test the behaviour of some popular stdlib
> implementations (e.g., STLPort/SGI, Metrowerks, Dinkumware, old
> Dinkumware in VC++, Borland) they show embarassingly different
> behaviours for specific values of the parameters, as soon as the ranges
> involved begin to overlap. Is there any undefined behaviour lurking
> here?

The only embarassment, if there is any, is that the C++ Standard changed
over the several years before it froze. The committee determined along the
way that overlapping operands should work unsurprisingly for template class
basic_string. You had to get the same answer as if the operands did not
overlap. Hence, ``old Dinkumware in VC++'' does not try to get overlap right
and ``Dinkumware'' gets it right, as required by the final C++ Standard.
Other libraries tend not to get overlap right, but they seem to be falling
into line.

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"P.J. Plauger" wrote:

> The only embarassment, if there is any, is that the C++ Standard changed
> over the several years before it froze. The committee determined along the
> way that overlapping operands should work unsurprisingly for template class
> basic_string. You had to get the same answer as if the operands did not
> overlap. Hence, ``old Dinkumware in VC++'' does not try to get overlap right
> and ``Dinkumware'' gets it right, as required by the final C++ Standard.
> Other libraries tend not to get overlap right, but they seem to be falling
> into line.

Thanks for your clarification, with which I agree, of course.

However, I'm still curious to know which is the *specific* C++ Standard section enforcing
this...

For sure, a library which does not try to get the overlap right in those "pathological"
situations makes the life easier to the implementor ;-) and maybe can be a little bit less
memory ungry (e.g., one less temporary string in the implementation of
basic_string::replace?!?)

Thanks,
Paolo.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Paolo Carlini" <pcarlini@unitus.it> wrote in message news:3BB39FA5.C7F500A@unitus.it...

> However, I'm still curious to know which is the *specific* C++ Standard section enforcing
> this...

It's the dog that didn't bark. We determined that the C++ Standard nowhere says
that string operands must not overlap. Therefore, overlap must be permitted, and
the semantics are as specified for non-overlapping operands.

After we determined that, we decided that's what we meant. It was a weightless
change after some discussion.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]