* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
@ 2020-05-19 13:55 ` terra at gnome dot org
2020-05-19 15:48 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: terra at gnome dot org @ 2020-05-19 13:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
2020-05-19 13:55 ` [Bug libstdc++/95209] " terra at gnome dot org
@ 2020-05-19 15:48 ` redi at gcc dot gnu.org
2020-05-21 12:26 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2020-05-19 15:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
2020-05-19 13:55 ` [Bug libstdc++/95209] " terra at gnome dot org
2020-05-19 15:48 ` redi at gcc dot gnu.org
@ 2020-05-21 12:26 ` redi at gcc dot gnu.org
2020-05-21 12:32 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2020-05-21 12:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
` (2 preceding siblings ...)
2020-05-21 12:26 ` redi at gcc dot gnu.org
@ 2020-05-21 12:32 ` redi at gcc dot gnu.org
2020-05-21 16:59 ` terra at gnome dot org
2020-05-21 19:33 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2020-05-21 12:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
` (3 preceding siblings ...)
2020-05-21 12:32 ` redi at gcc dot gnu.org
@ 2020-05-21 16:59 ` terra at gnome dot org
2020-05-21 19:33 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: terra at gnome dot org @ 2020-05-21 16:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"
2020-05-19 13:53 [Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo" terra at gnome dot org
` (4 preceding siblings ...)
2020-05-21 16:59 ` terra at gnome dot org
@ 2020-05-21 19:33 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2020-05-21 19:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread