[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
marxin at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Mar 12 18:47:32 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
commit r9-8369-g7ef07b622d8c2fca35813bf50669dcd663fe5cf2
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Mar 12 17:39:05 2020 +0000
libstdc++: Handle type-changing path concatenations (PR 94063)
The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.
For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".
Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.
This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated.
Backport from mainline
2020-03-09 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge
to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view<value_type>)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.
More information about the Gcc-bugs
mailing list