aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2020-03-09 23:22:57 +0000
committerJonathan Wakely <jwakely@redhat.com>2020-03-09 23:22:57 +0000
commitea182fe63634bb5b7913b3f1b6846e1900c5e0c4 (patch)
tree038fadb07c156fa32263ca3f5d6b5a8b2fc89ce1 /gcc
parent81fa6d7321dd9b645d86de4a8a6967c603f176e3 (diff)
downloadgcc-ea182fe63634bb5b7913b3f1b6846e1900c5e0c4.zip
gcc-ea182fe63634bb5b7913b3f1b6846e1900c5e0c4.tar.gz
gcc-ea182fe63634bb5b7913b3f1b6846e1900c5e0c4.tar.bz2
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. That can be fixed later though. 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.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions