[Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo"

[Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

            Bug ID: 95209
           Summary: std::filesystem::path::lexically_normal mangles
                    "//foo"
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 48566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48566&action=edit
test program

lexically_normal transforms "//foo" into "/foo".  It should leave
two initial slashes (an alternate root) alone.

Output of upcoming program is "/foo" when it should be "//foo".

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

--- Comment #1 from M Welinder <terra at gnome dot org> ---
Created attachment 48567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48567&action=edit
preprocessed test program

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You didn't provide the requested information when creating a new bug report,
please see https://gcc.gnu.org/bugs/


(In reply to M Welinder from comment #0)
> lexically_normal transforms "//foo" into "/foo".  It should leave
> two initial slashes (an alternate root) alone.

That's implementation defined. This implementation only gives special handling
to paths starting with "//" for Cygwin. The path "//foo" has no special meaning
for other platforms.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-05-21
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> You didn't provide the requested information when creating a new bug report,
> please see https://gcc.gnu.org/bugs/

We're missing the output of 'gcc -v' but the preprocessed source shows the
target is x86_64-suse-linux, and so this is the expected (and
standard-conforming) behaviour.

What meaning does //foo have on linux? As far as I know the linux kernel
doesn't give it any special meaning.

So for linux targets libstdc++ has a single implementation-defined root-name,
which is the empty string and is never matched in a path.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

--- Comment #4 from M Welinder <terra at gnome dot org> ---
Sorry about the missing "-v".  It is indeed a x86_64-suse-linux system.  (It's
not internet facing or I'd go get the full output.)

"Implementation defined", yes, but the implementation is the os, not the
compiler/library.  The OS gets to choose and, possibly, change its mind
long after the compiler has written its output.

> What meaning does //foo have on linux?

Today, nothing separate, tomorrow who knows?  The OS is at perfect liberty to
assign a different meaning on Fridays if it so pleases.  Run the linux binary
on windows today and I suspect, but haven't verified, that it matters right
now.

Note that "cd //tmp" in bash shows that bash takes care not to mangle it.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to M Welinder from comment #4)
> Sorry about the missing "-v".  It is indeed a x86_64-suse-linux system. 
> (It's not internet facing or I'd go get the full output.)
> 
> "Implementation defined", yes, but the implementation is the os, not the
> compiler/library.

No, that's wrong.

"This document specifies requirements for implementations of the C ++
programming language."

The OS is not an implementation of the C++ programming language. GCC is.

>  The OS gets to choose and, possibly, change its mind
> long after the compiler has written its output.

The OS gets to choose whether that path has any effect for system calls to t he
OS, but it's the C++ implementation that chooses the definition of root-name in
the std::filesystem library.

> > What meaning does //foo have on linux?
> 
> Today, nothing separate, tomorrow who knows?  The OS is at perfect liberty
> to assign a different meaning on Fridays if it so pleases.  Run the linux
> binary
> on windows today and I suspect, but haven't verified, that it matters right
> now.

If you can verify that I'd be interested, but not in a suspicion.

> Note that "cd //tmp" in bash shows that bash takes care not to mangle it.