public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
@ 2021-03-01 21:45 moritz at bunkus dot org
  2021-03-02 10:40 ` [Bug libstdc++/99333] " redi at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: moritz at bunkus dot org @ 2021-03-01 21:45 UTC (permalink / raw)
  To: gcc-bugs

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
@ 2021-03-02 10:40 ` redi at gcc dot gnu.org
  2021-03-02 11:50 ` redi at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-02 10:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-03-02
             Target|                            |*-*-mingw*

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
  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
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-02 11:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The problem is not path::is_absolute(), it's path::has_root_name(), which (by
design) only handles //rootname on Cygwin:

#ifdef __CYGWIN__
// Interpret "//x" as a root-name, not root-dir + filename
# define SLASHSLASH_IS_ROOTNAME 1
#endif


I don't have boost built for mingw. Does boost recognise "//disky/mosu" as a
valid path, or does a UNC root-name have to use backslashes?

i.e. is path("//disky/mosu").has_root_name() true?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
  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
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: moritz at bunkus dot org @ 2021-03-02 12:24 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

--- Comment #2 from Moritz Bunkus <moritz at bunkus dot org> ---
The following code tests forward & backward slashes with both std::filesystem
(gcc 10.2.0, mingw via MXE) and boost::filesystem (Boost 1.74.0):

  auto slashes     = R"(//server/share/file.txt)"s;
  auto backslashes = R"(\\server\share\file.txt)"s;

  std::cout << "std::filesystem::path("   << slashes     << ").has_root_name()
" << std::filesystem::path{slashes}.has_root_name()       << "\n"
            << "std::filesystem::path("   << backslashes << ").has_root_name()
" << std::filesystem::path{backslashes}.has_root_name()   << "\n"
            << "boost::filesystem::path(" << slashes     << ").has_root_name()
" << boost::filesystem::path{slashes}.has_root_name()     << "\n"
            << "boost::filesystem::path(" << backslashes << ").has_root_name()
" << boost::filesystem::path{backslashes}.has_root_name() << "\n";

The output of that snippet is:

std::filesystem::path(//server/share/file.txt).has_root_name() 0
std::filesystem::path(\\server\share\file.txt).has_root_name() 0
boost::filesystem::path(//server/share/file.txt).has_root_name() 1
boost::filesystem::path(\\server\share\file.txt).has_root_name() 1

Or to put it differently, std::filesystem doesn't seem to care either way while
Boost recognizes both.

Note that __CYGWIN__ is not defined with the compiler from MXE! I'm not
compiling on Windows. This is a cross-compiler, from Linux to Windows. What is
defined are things such as:

[0 mosu@sweet-chili ~] x86_64-w64-mingw32.static-g++ -dM -E -x c++ - <
/dev/null | sort | grep -E 'WINNT|WIN(32|64)|MINGW'
#define __MINGW32__ 1
#define __MINGW64__ 1
#define __WIN32 1
#define __WIN32__ 1
#define _WIN32 1
#define WIN32 1
#define __WIN64 1
#define __WIN64__ 1
#define _WIN64 1
#define WIN64 1
#define __WINNT 1
#define __WINNT__ 1
#define WINNT 1

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
                   ` (2 preceding siblings ...)
  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
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-02 13:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Moritz Bunkus from comment #2)
> while Boost recognizes both.

That's what I wanted to know, thanks.

> Note that __CYGWIN__ is not defined with the compiler from MXE!

Obviously, because it's not cygwin. Which is why //x paths are not treated as a
root-name. As I said, that's by design, but can be changed.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
                   ` (3 preceding siblings ...)
  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
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: moritz at bunkus dot org @ 2021-03-02 13:19 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

--- Comment #4 from Moritz Bunkus <moritz at bunkus dot org> ---
Oh right, sorry — I misread your earlier comment.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
                   ` (4 preceding siblings ...)
  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
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-08  9:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=99430

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
                   ` (5 preceding siblings ...)
  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
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-06  8:30 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |12.2

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
  2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
                   ` (6 preceding siblings ...)
  2022-05-06  8:30 ` jakub at gcc dot gnu.org
@ 2022-05-06 12:33 ` redi at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-06 12:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.2                        |---

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-05-06 12:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-01 21:45 [Bug libstdc++/99333] New: std::filesystem::path().is_absolute() thinks UNC paths aren't absolute moritz at bunkus dot org
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

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).