From: <sten.kristian.ivarsson@gmail.com>
To: <cygwin@cygwin.com>
Cc: "'René Berber'" <rene.berber@gmail.com>
Subject: Sv: g++ and c++17 filesystem
Date: Thu, 19 Nov 2020 11:03:23 +0100 [thread overview]
Message-ID: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> (raw)
In-Reply-To: <D3704C33-A283-40F0-990D-CB9806F0B09D@gmail.com>
> > 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin <cygwin@cygwin.com>:
> >
> > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
> >
> >>>> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
> >>>
> >>>> The filesystem-library as a part of C++17 seems to have some
> >>>> defects and flaws in the cygwin-package and pretty much every
> >>>> lexical- and canonical operation works in mysterious ways (or not
> >>>> at all)
> >>> [snip]
> >>>
> >>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
[snip]
> As stated earlier, it seems like using mingw g++/libstdc++ (from the
> cygwin-package-manager) it seems like it works better, but then you can’t
> mix with other posix/cygwin mechanism (that uses cygstdc++) without
> breaking ODR (and probably some memory models etc as well) so maybe
> someone do have some insightful info about this ? How “special” is
> cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in that
> library (cygstdc++) ?
I think the problem can be viewed in /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/bits/fs_path.h and
...
#if defined(_WIN32) && !defined(__CYGWIN__)
# define _GLIBCXX_FILESYSTEM_IS_WINDOWS 1
# include <algorithm>
#endif
...
that when build in CYGWIN will make the stdc++ think it is not on Windows (and I guess cygstdc++-6.dll will be built without _GLIBCXX_FILESYSTEM_IS_WINDOWS implicitly), thus, the std::filesystem-library will act as it is on a Posix-system, but it is not and thus it makes wrong assumptions
It seems like the (ordinary) MinGW-shipping includes these directives (!defined(__CYGWIN__)) as well and my naive take on this is that it is a (the) mistake
The underlaying filesystem IS Windows and NOT Posix, but my guess is that (some) Posix-system-calls and/or assuming Posix-style-paths are invoked when _GLIBCXX_FILESYSTEM_IS_WINDOWS is not set
I guess the correct way would be to let _GLIBCXX_FILESYSTEM_IS_WINDOWS and maybe just have a #ifdef (__CYGWIN__) as an extra option ONLY when handling lexical stuff, i.e. it allows both Windows- and Posix-styles but the system calls should always be Windows calls (and I guess this would imply better performance as well to not need to walk through the whole Cygwin-posix-abstraction)
I might be totally wrong, so does anyone have any take on this ?
Best regards,
Kristian
> Best regards,
> Kristian
[snip]
next prev parent reply other threads:[~2020-11-19 10:03 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 ` sten.kristian.ivarsson [this message]
2020-11-19 15:27 ` Sv: " 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 ` Sv: " sten.kristian.ivarsson
2020-11-20 18:28 ` 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='000a01d6be5b$3808cad0$a81a6070$@gmail.com' \
--to=sten.kristian.ivarsson@gmail.com \
--cc=cygwin@cygwin.com \
--cc=rene.berber@gmail.com \
/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).