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

[sten.kristian.ivarsson@gmail.com]

> Ok, first, I admit that I was not familiar with the details of
> std::filesystem.  However, after looking at it, I remain unsurprised that
> the Cygwin and Mingw versions might be different.  (I would also not be
> surprised if there is a real bug in there.)

At least semantic bugs considering the whole concept

> The behavior I would _expect_ is that the Cygwin version will work using
Posix sorts of assumptions.

I guess it will to, but then your application have to ensure that in every
place the application uses a file path and the reasons we do have
(platform-independent) libraries is to not having to do that

> While a root of C: (for example) _might_ work, /cygdrive/c is more
> normative on Cygwin.

Yes, but to what purpose ? What applications do explicitly handle any root
directory (except for possibly /tmp or /dev/null) ?

(I put a link to that in Cygwin's / called c, so
> 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)

> 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

> I "get" that you want to write portable programs that use this interface,
> which is analogous to the Java file path classes.  In terms of how this
> interface works, I would expect it to _claim_ that it is Posix, not
> Windows, because the paths Cygwin supports are Posix style (it _will_
> recognize a few Windows idioms, but it is correct in not advertising
> itself as Windows).
> 
> So it you want to do Windows-style (but abstracted with this library), I
> direct you to Mingw.  Each has its place.  Cygwin allows one to pretend,
> pretty successfully though with a few small rough edges, that one is on
> Linux, not Windows.  That is its intent.  Mingw gives you the gcc/gnu
> toolchain and libraries under Windows.

As stated earlier, we're using Cygwin to be able to keep some kind of cross
platform code base and Cygwin offers non-cross-platform-standardized
libraries/api:s (i.e. posix) to be executable without having to #ifdef the
code base to be buildable and executable on Windows but MinGW doesn't supply
those posix libraries on Windows (maybe a few), so using GCC/MinGW is not an
option and I guess we'd go with MSVC if we wanted to port our code
completely

std::filesystem is supposed to be cross-platform (and easier to use than
various posix-library-C-functions) though and it is cross-platform per
definition but, then again, not when using Cygwin

> I hope we're not still talking at cross purposes, though that it certainly
> possible!
> 
> Best wishes - EM
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple