From: <sten.kristian.ivarsson@gmail.com>
To: <moss@cs.umass.edu>, <cygwin@cygwin.com>
Subject: Sv: Sv: g++ and c++17 filesystem
Date: Fri, 20 Nov 2020 09:31:04 +0100 [thread overview]
Message-ID: <000201d6bf17$7cc4beb0$764e3c10$@gmail.com> (raw)
In-Reply-To: <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu>
> 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
next prev parent reply other threads:[~2020-11-20 8:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 15:15 sten.kristian.ivarsson
2020-11-17 16:45 ` René Berber
2020-11-18 9:00 ` Sv: " sten.kristian.ivarsson
2020-11-18 16:24 ` René Berber
2020-11-18 16:31 ` Eliot Moss
2020-11-18 20:46 ` Kristian Ivarsson
2020-11-18 20:56 ` Eliot Moss
2020-11-18 21:18 ` Kristian Ivarsson
2020-11-18 23:47 ` Eliot Moss
2020-11-19 8:10 ` Sv: " sten.kristian.ivarsson
2020-11-18 21:45 ` Norton Allen
2020-11-19 0:08 ` Doug Henderson
2020-11-19 6:23 ` Brian Inglis
2020-11-19 10:03 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:27 ` Brian Inglis
2020-11-20 9:37 ` Sv: " sten.kristian.ivarsson
2020-11-20 15:29 ` Brian Inglis
2020-11-20 16:11 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:36 ` Eliot Moss
2020-11-20 8:31 ` sten.kristian.ivarsson [this message]
2020-11-20 18:28 ` Sv: " Jonathan Yong
[not found] ` <000601d6c173$aa55d540$ff017fc0$@gmail.com>
2020-11-23 11:09 ` Sv: " Jonathan Yong
2020-11-24 9:32 ` Sv: " sten.kristian.ivarsson
2020-11-24 10:24 ` Jonathan Yong
2020-11-24 11:35 ` Sv: " sten.kristian.ivarsson
2020-11-24 12:33 ` Jonathan Yong
2020-11-24 14:01 ` Sv: " sten.kristian.ivarsson
2020-11-25 2:25 ` Jonathan Yong
2020-11-24 13:22 ` Eliot Moss
2020-11-24 14:31 ` Sv: " sten.kristian.ivarsson
2020-11-24 20:06 ` Ken Brown
2020-11-24 20:39 ` Eliot Moss
2020-11-25 8:02 ` Sv: " sten.kristian.ivarsson
2020-11-25 8:30 ` sten.kristian.ivarsson
2020-11-25 0:23 ` Brian Inglis
2020-11-25 9:00 ` Sv: " sten.kristian.ivarsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000201d6bf17$7cc4beb0$764e3c10$@gmail.com' \
--to=sten.kristian.ivarsson@gmail.com \
--cc=cygwin@cygwin.com \
--cc=moss@cs.umass.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).