Sv: Sv: Sv: Sv: g++ and c++17 filesystem

[<sten.kristian.ivarsson@gmail.com>]

> On 11/23/20 8:35 AM, sten.kristian.ivarsson@gmail.com wrote:
> >> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
> >>>> that, for me, /c works.)  Likewise, I would expect the normative
> >>>> path separator to be / not \, and an absolute path to start with /.
> >>>> Windows offers several kinds of symlinks, with varying semantics,
> >>>> so the detailed behavior of that would be affected by the settings
> >>>> in the CYGWIN environment variable
> >>>
> >>> All the implementations of std::filesystem I've seen so far, is
> >>> agnostic to whether / or \ is used as a path separator (but the
> >>> generic form is '/' and a fun fact, the MSVC-implementation of
> >>> std::filesystem handles the generic
> >>> (posix) form more close to the standard specification than GCC)
> >>>
> >>
> >> That is not correct, \ is a valid filename under *nix, but not on
> Windows.
> >> I don't think the standards specify what filenames or character sets
> >> are valid. Cygwin strives for *nix compatibility, anything else is
> secondary.
> >
> >
> > I should have made my point clear; "All the implementations of
> std::filesystem for Windows ..."
> >
> >
> 
> That is an incorrect understanding, Cygwin is NOT Windows, it is its own
> platform, you should not consider it even Windows unless you are working
> on Cygwin internals.

I beg to differ. My claim was that all the std::filesystem implementations I've seen for Windows, except Cygwin, handles both '\' and '/' and that was my point (Cygwin handles it in some circumstances) so that point is perfectly valid

I'm not considering either '/' or '\' in the code. I'm working with a path. I don't care what kind of separators the path handled to the application have. I want std::filesystem to work properly even if the folder-separator in current platform is ¤#¤#¤#¤

> >>>> I would expect std::filesystem to present paths to construct paths
> >>>> to present to underlying library calls such as open ... and on
> >>>> Cygwin, open uses Posix style paths.
> >>>
> >>> I consider that to be a mistake in the implementation of
> >>> std::filesystem, because on Windows the preferred style would be smt
> >>> like C:/ and then as an opt-out it would consider /cygdrive/c (or
> >>> such) as a valid thing as well
> >>>
> >>
> >> Cygwin is not Windows, it runs on Windows, but it is not Windows. You
> >> should use mingw if you want Windows style paths. There isn't a
> >> magical tool that allows you to have it both ways.
> >
> > As I'm trying to say, Cygwin already accepts Windows-style-paths in some
> circumstances and thus it have SOME magic, so why not extend that and thus
> make it easier to use Cygwin on its target platform, i.e. Windows ?
> >
> 
> Because libstdc++ is not part of Cygwin, it is part of the GCC project,
> developed by completely different developers. GCC runs on Cygwin, so it is
> expected to use standard *nix API, not windows. Windows path conversions
> are entirely unreliable, see the mess that is MSYS, when Windows and *nix
> paths collide.

I think you have misunderstood my point completely. I know that they are unreliable and that's what I'm trying to have a discussion about, because I cannot see why it has to be unreliable and how it not could be fixed

> > As I've said, to use MinGW along with Cygwin would be very tricky
> > without bumping into ODR/memory issues
> >
> > I don't think MinGW alone give us enough support alone to keep our
> > code base non platform specific (*nix+windows)
> >
> >
> 
> If you are on Cygwin, use *nix APIs and paths, that's the end to it. You
> should not mix Cygwin compiled code with MinGW.

About the code, that's exactly as I stated 

> >>
> >> Yes, cross platform, you can use std::filesystem on Linux, Cygwin,
> >> Windows, Macs, but it certainly cannot do anything that can't be
> >> handled for the underlying platform. For Cygwin, it means using *nix
> >> paths, not Windows.
> >
> > Exactly, so why obfuscate the underlaying platform with a Posix-layer
> that also can do exactly just what the underlaying platform can and then
> back to some standard interface again (i.e. std::filesystem) which make a
> roundtrip that only can result in loss of information/functionality ?
> >
> 
> Because Cygwin is exactly that, to emulate POSIX layer on Windows, if
> POSIX mandates exposing Windows paths, then you would see Cygwin reworked
> to support it.
> 
> > I rather have a dialogue of how that that could be done rather than
> "Cygwin is *nix, deal with it" or at least it would be nice to hear if
> someone do have some insightful thoughts of why it must the way it is or
> why it would be so hard to make parts (e.g. std::filesystem) more useful ?
> >
> >
> 
> That's not what Cygwin is for, you ignore everything while conveniently
> claiming to be looking for "insightful thoughts". You still haven't
> answered where is it in the POSIX standard requires backslashes to be used
> as separator or how are you going to make other *nix platforms accept such
> a change? 

Did I get a question about where I think that POSIX requires backslashes or did I make such claim ? If one of them, I have missed that question and I have certainly not made any such claim

All I'm saying is that I'd like std::filesystem in Cygwin to work properly and I still cannot see why that cannot happen ?

What would the drawbacks be if std::filesystem worked more transparent (i.e. correct) and made Cygwin more useful ? I don't think the community would shrink !

Kristian