public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "moritz at bunkus dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute Date: Mon, 01 Mar 2021 21:45:13 +0000 [thread overview] Message-ID: <bug-99333-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333 Bug ID: 99333 Summary: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: moritz at bunkus dot org Target Milestone: --- Created attachment 50280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50280&action=edit test case Compiling with gcc 10.2.0 from the mxe cross compilation environment for Windows. The attached sample program says it all. It shows that std::filesystem::("\\server\share\file.txt").is_absolute() is false and turns std::filesystem::absolute("\\server\share\file.txt") into something like "C:\server\share\file.txt". boost::filesystem::path(…).is_aboslute(), on the other hand, considers UNC paths absolute & leaves them unmodified via boost::filesystem::absolute(…) The test program outputs the following: std::filesystem: original \\disky\mosu\existing_file.txt is_absolute 0 absolute "C:\\disky\\mosu\\existing_file.txt" boost::filesystem: original \\disky\mosu\existing_file.txt is_absolute 1 absolute "\\disky\mosu\existing_file.txt" Compile with something like: x86_64-w64-mingw32.static-g++ -std=c++17 \ -I/home/mosu/prog/video/mingw/cross/usr/x86_64-w64-mingw32.static/include \ -L/home/mosu/prog/video/mingw/cross/usr/x86_64-w64-mingw32.static/lib \ -o std_filesystem_unc_paths_vs_absolute.exe \ std_filesystem_unc_paths_vs_absolute.cpp \ -lboost_filesystem-mt-s-x64 -lboost_system-mt-s-x64
next reply other threads:[~2021-03-01 21:45 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-01 21:45 moritz at bunkus dot org [this message] 2021-03-02 10:40 ` [Bug libstdc++/99333] " redi at gcc dot gnu.org 2021-03-02 11:50 ` redi at gcc dot gnu.org 2021-03-02 12:24 ` moritz at bunkus dot org 2021-03-02 13:05 ` redi at gcc dot gnu.org 2021-03-02 13:19 ` moritz at bunkus dot org 2021-04-08 9:42 ` redi at gcc dot gnu.org 2022-05-06 8:30 ` jakub at gcc dot gnu.org 2022-05-06 12:33 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99333-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).