public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-09 13:21 ` redi at gcc dot gnu.org
2020-03-10 10:34 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2020-03-09 13:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The test case for Cygwin (which is expected to fail on other targets) is
#include <filesystem>
#include <assert.h>
using std::filesystem::path;
int main()
{
path p;
p = "/";
p += path("/x");
assert( p.has_root_name() );
assert( p.root_name() == p );
p = "/";
p += "/x";
assert( p.has_root_name() );
assert( p.root_name() == p );
p = "/";
p += path("/");
assert( !p.has_root_name() );
assert( p.has_root_directory() );
p = "/";
p += "/";
assert( !p.has_root_name() );
assert( p.has_root_directory() );
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
2020-03-09 13:21 ` [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths redi at gcc dot gnu.org
@ 2020-03-10 10:34 ` redi at gcc dot gnu.org
2020-03-11 12:06 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2020-03-10 10:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |9.4
Status|NEW |ASSIGNED
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for master with r10-7095-gea182fe63634bb5b7913b3f1b6846e1900c5e0c4
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.
I plan to fix this for gcc 9.4 later. A more efficient fix would also be
possible.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
2020-03-09 13:21 ` [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths redi at gcc dot gnu.org
2020-03-10 10:34 ` redi at gcc dot gnu.org
@ 2020-03-11 12:06 ` marxin at gcc dot gnu.org
2020-03-12 17:40 ` redi at gcc dot gnu.org
2020-03-12 18:47 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-11 12:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marxin at gcc dot gnu.org
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
commit r10-7095-gea182fe63634bb5b7913b3f1b6846e1900c5e0c4
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Mar 9 23:22:57 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. 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-03-11 12:06 ` marxin at gcc dot gnu.org
@ 2020-03-12 17:40 ` redi at gcc dot gnu.org
2020-03-12 18:47 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2020-03-12 17:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 9.4
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-03-12 17:40 ` redi at gcc dot gnu.org
@ 2020-03-12 18:47 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-12 18:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-03-12 18:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-94063-4@http.gcc.gnu.org/bugzilla/>
2020-03-09 13:21 ` [Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths redi at gcc dot gnu.org
2020-03-10 10:34 ` redi at gcc dot gnu.org
2020-03-11 12:06 ` marxin at gcc dot gnu.org
2020-03-12 17:40 ` redi at gcc dot gnu.org
2020-03-12 18:47 ` marxin at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).