[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Fri Feb 8 12:20:03 2019
New Revision: 268681
URL: https://gcc.gnu.org/viewcvs?rev=268681=gcc=rev
Log:
PR libstdc++/89117 backport path::replace_extension("") fix
Although the reported bug isn't present on the branch, adjusting the
final component avoids leaving a broken invariant in case of an
exception.
Backport from mainline
2019-01-30 Jonathan Wakely
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/src/filesystem/std-path.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- .
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 30 23:18:22 2019
New Revision: 268406
URL: https://gcc.gnu.org/viewcvs?rev=268406=gcc=rev
Log:
PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
--- Comment #3 from Jonathan Wakely ---
Fixed, thanks for the report.
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 30 23:18:22 2019
New Revision: 268406
URL: https://gcc.gnu.org/viewcvs?rev=268406=gcc=rev
Log:
PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
--- Comment #3 from Jonathan Wakely ---
Fixed, thanks for the report.
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-30 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Hannes Hauswedell from comment #0) > This leads to very unexpected behaviour without prior > warning or error. Well yes, that's often the nature of bugs :-)
