g++ and c++17 filesystem

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

g++ and c++17 filesystem

Cygwin list mailing list
Hi folks

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)


Following output with g++cygwin

 $ uname -a
 CYGWIN_NT-10.0 JOKK 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

 $ g++ --version
 g++ (GCC) 10.2.0
 Copyright (C) 2020 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ g++ -std=c++17 main.cpp

 $ ./a.exe
 true
 C:/Temp
 filesystem error: cannot make canonical path: No such file or directory
[C:/Temp]


Following output with mingw (that also is a bit strange (note the last
"generic" (i.e. posix) output))

 $ .\g++.exe --version
 g++.exe (MinGW.org GCC Build-2) 9.2.0
 Copyright (C) 2019 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ .\g++.exe -std=c++17 main.cpp

 $ .\a.exe
 true
 C:/Temp
 C:\Temp


Following output with cl (that seems to be the most standard-conformant)

 C:\>cl /std:c++17 main.cpp
 Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x86
 Copyright (C) Microsoft Corporation.  All rights reserved.

 main.cpp

 /out:main.exe
 main.obj

 C:\>main.exe
 true
 C:/Temp
 C:/Temp



I have failed to find out exactly where the defect are though and I also do
have a hard time to see where/how/if there's a gcc/g++/mingw- or
libstdc++-fork for the cygwin package where this breaks


Does anyone have any ideas about this and know of any patches or (hot)fixes
to this ?

I haven't tried out all the mingw generic/lexical/canonical functions yet,
but maybe they're flawed as well


Thanx in advance



Best regards,
Kristian





--
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

main.cpp (661 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Cygwin list mailing list
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

--
R.Berber
--
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
Reply | Threaded
Open this post in threaded view
|

Sv: g++ and c++17 filesystem

Cygwin list mailing list
> 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

So by this you're saying that cygwin-applications cannot handle the
filesystem it is supposed to handle ?

How come std::filesystem first say "It's a valid file" followed by "It's not
a valid file" ? Is that part of the "circumvention" ?

In the current use case, the path is even returned from
std::filesystem::directory_iterator where it says "Hey, here's a path to a
file I found in the folder you pointed out" followed by "The path I just
gave to you is not a valid path"

It's gonna be tricky to implement applications in that way




Best regards,
Kristian



> --
> R.Berber
> --
> 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

--
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
Reply | Threaded
Open this post in threaded view
|

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

Cygwin list mailing list
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
>
> So by this you're saying that cygwin-applications cannot handle the
> filesystem it is supposed to handle ?

I'm not saying anything, I'm pointing to the relevant documentation.

> How come std::filesystem first say "It's a valid file" followed by "It's not
> a valid file" ? Is that part of the "circumvention" ?

The documentation states that using Windows notation is not supported
and may result in unexpected results (i.e. sometimes work, sometimes
doesn't).

> In the current use case, the path is even returned from
> std::filesystem::directory_iterator where it says "Hey, here's a path to a
> file I found in the folder you pointed out" followed by "The path I just
> gave to you is not a valid path"
>
> It's gonna be tricky to implement applications in that way

The problem is that your assumptions and expectations are wrong.  Not
knowing Cygwin that is expected.

Cygwin handles the file system with no problem, but using Posix-like
notation, not Windows-like.  End of story.
--
R.Berber
--
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
Reply | Threaded
Open this post in threaded view
|

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

Eliot Moss
On 11/18/2020 11:24 AM, René Berber via Cygwin wrote:

> Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.  
> End of story.

And I'll add, this is by design: Cygwin's goal is to provide a programming (and command line)
environment as much like Posix as reasonably possible.

It does include some tools to help interface with Windows more explicitly, such as cygpath and
cygstart.  I have defined a bash alias ppt that refers to a bach function powerpnt, defined thusly:

powerpnt ()
{
     local ARG;
     [ -n "$1" ] && {
         ARG="$(cygpath -wa "$1")";
         shift
     };
     [ -n "$VERBOSE" ] && {
         echo powerpnt ${ARG:+"${ARG}"} "$@"
     };
     command powerpnt ${ARG:+"${ARG}"} "$@" &
}

This takes the first argument and converts it from Posix to Windows form, for passing to the
powerpnt binary.  And then I have a file system link so that "command powerpnt" gets to the
installed Windows binary C:\Program Files.

But this is by far the exception as opposed to the rule in how I use Cygwin.

In hope that this give you some perspective and insight as to what Cygwin is and why.

Best wishes - Eliot Moss
--
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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Cygwin list mailing list
In reply to this post by Cygwin list mailing list

> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin <[hidden email]>:
>
> 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
>> So by this you're saying that cygwin-applications cannot handle the
>> filesystem it is supposed to handle ?
>
> I'm not saying anything, I'm pointing to the relevant documentation.
>
>> How come std::filesystem first say "It's a valid file" followed by "It's not
>> a valid file" ? Is that part of the "circumvention" ?
>
> The documentation states that using Windows notation is not supported and may result in unexpected results (i.e. sometimes work, sometimes doesn't).
[snip]
> Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.  End of story.
Well, the sole reason behind this question was to either find an existing solution to this issue or perhaps invoke some work to improveme CYGWIN, because no developer, operator or user likes undefined behaviour and I think that we all can agree to that it would be kind of nifty if this worked as expected and thus I don’t consider this to be the end of the story

I’m thankful that you pointed out the documentation (that I already have read some while ago) and by “you” I didn’t mean you in person but more directed to the “community”

The only purpose CYGWIN have is to make/build posix-applications runnable on Windows and applications usually have user defined input, such as paths etc, and on Windows that input is usually Windows-native-paths unless you educate operators/users to enter paths with /cygdrive/...

... or you have to add code to kind of transform possible Windows-paths to Posix-paths (perhaps back and forth), well then you’re adding non-posix-logic (non-cross-platform-logic) to your application and that makes it one reason less to use CYGWIN

Is there any other use cases for CYGWIN than to build applications running in Windows ? Do people use CYGWIN (shell) to operate or monitor their applications ? For all other use cases than the development (the shell) I cannot see why CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ?

So, a library can always go from undefined to defined without breaking changes, so does anyone know what the effort could be to fix this, i.e. make it work transparently/agnostic ?

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++) ?

Best regards,
Kristian

> --
> R.Berber
> --
> 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Eliot Moss
I would agree that if you want an executable that acts and feels more like a Windows native
application, then mingw is probably what you want.  Cygwin is if you want something that acts and
feels more like a Posix thing ... which means it will be oriented to Posix style paths.

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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Cygwin list mailing list

> I would agree that if you want an executable that acts and feels more like a Windows native application, then mingw is probably what you want.  Cygwin is if you want something that acts and feels more like a Posix thing ... which means it will be oriented to Posix style paths.
To be able to use mingw all the code have to be ported to use Windows native mechanisms and then we might just use MSVC instead

We don’t want (either) Windows-style-paths or Posix-style-paths, we want A path and expect it to work equally regardless of what platform is used in regards to std::filesystem

As far as I see, very few applications do form their own - and/or have hard-coded absolute paths and instead they are usually input data (through UI, configuration, OS, environment or such)


> 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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Norton Allen
In reply to this post by Cygwin list mailing list
On 11/18/2020 3:46 PM, Kristian Ivarsson via Cygwin wrote:
> Is there any other use cases for CYGWIN than to build applications running in Windows ? Do people use CYGWIN (shell) to operate or monitor their applications ? For all other use cases than the development (the shell) I cannot see why CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ?

To write software that can be compiled and run under Windows, Linux and
MacOS.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Eliot Moss
In reply to this post by Cygwin list mailing list
On 11/18/2020 4:18 PM, Kristian Ivarsson wrote:
>
>> I would agree that if you want an executable that acts and feels more like a Windows native application, then mingw is probably what you want.  Cygwin is if you want something that acts and feels more like a Posix thing ... which means it will be oriented to Posix style paths.
> To be able to use mingw all the code have to be ported to use Windows native mechanisms and then we might just use MSVC instead
>
> We don’t want (either) Windows-style-paths or Posix-style-paths, we want A path and expect it to work equally regardless of what platform is used in regards to std::filesystem
>
> As far as I see, very few applications do form their own - and/or have hard-coded absolute paths and instead they are usually input data (through UI, configuration, OS, environment or such)

IN this context, I would say "Which std::filesystem?  The Cygwin Posix-like one or the mingw
Windows-like one?"  If you want uniformity, I'd go with Cygwin; it you want platform-like behavior,
then mingw.

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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Cygwin list mailing list
In reply to this post by Cygwin list mailing list
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson via Cygwin
<[hidden email]> wrote:
>
>

> The only purpose CYGWIN have is to make/build posix-applications runnable on Windows and applications usually have user defined input, such as paths etc, and on Windows that input is usually Windows-native-paths unless you educate operators/users to enter paths with /cygdrive/...

<rant>
I use CYGWIN to work around a stupid design decision made by a small
time OS developer more than 40 years ago, and inherited by an OS that
did not even have directories in its first release.
</rant>

Doug

--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
--
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
Reply | Threaded
Open this post in threaded view
|

Re: g++ and c++17 filesystem

Brian Inglis
On 2020-11-18 17:08, Doug Henderson via Cygwin wrote:
> On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson wrote:
>> The only purpose CYGWIN have is to make/build posix-applications runnable
>> on Windows and applications usually have user defined input, such as paths
>> etc, and on Windows that input is usually Windows-native-paths unless you
>> educate operators/users to enter paths with /cygdrive/...

> <rant>
> I use CYGWIN to work around a stupid design decision made by a small
> time OS developer more than 40 years ago, and inherited by an OS that
> did not even have directories in its first release.
> </rant>

Actually, most of those design decisions were made in the 1950s-1960s by
scientific then mainframe OS designers in multiprocessing then multiuser
environments, and the short sighted decisions were made to get things working
quickly by people without much design or systems background (BGIII^Wcough!) in
some of the smaller minicomputer then microcomputer adaptations, which were
often frankly PoS hacks, and triumphs of salesmanship over competency. ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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
Reply | Threaded
Open this post in threaded view
|

Sv: g++ and c++17 filesystem

Cygwin list mailing list
In reply to this post by Eliot Moss
> >> I would agree that if you want an executable that acts and feels more
> like a Windows native application, then mingw is probably what you want.
> Cygwin is if you want something that acts and feels more like a Posix
> thing ... which means it will be oriented to Posix style paths.
> > To be able to use mingw all the code have to be ported to use Windows
> > native mechanisms and then we might just use MSVC instead
> >
> > We don’t want (either) Windows-style-paths or Posix-style-paths, we
> > want A path and expect it to work equally regardless of what platform
> > is used in regards to std::filesystem
> >
> > As far as I see, very few applications do form their own - and/or have
> > hard-coded absolute paths and instead they are usually input data
> > (through UI, configuration, OS, environment or such)
>
> IN this context, I would say "Which std::filesystem?  The Cygwin Posix-
> like one or the mingw Windows-like one?"  If you want uniformity, I'd go
> with Cygwin; it you want platform-like behavior, then mingw.


I'm referring to std::filesystem as a part of the C++17 standard (https://en.cppreference.com/w/cpp/filesystem) that is pretty well defined and quite agnostic to what "style" of path used as our application are and as I said, we don't care (we don't ever inspect them) what "style" of paths we're using but we expect a deterministic behaviour from that library regardless of operating system, such as and absolute path should be an absolute path regardless

That's the sole purpose of std::filesystem, i.e. to be platform independent (though all file-features is not applicable on all operating systems, but at least you can ask the library for those attributes)


GCC/MinGW support platform-INDEPENDENT-behaviour because gcc/g++ works equally regardless if Linux or Windows in regards to std::filesystem


Best regards,
Kristian


> 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

--
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
Reply | Threaded
Open this post in threaded view
|

Sv: g++ and c++17 filesystem

Cygwin list mailing list
In reply to this post by Cygwin list mailing list
> > 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin <[hidden email]>:
> >
> > 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]


--
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
Reply | Threaded
Open this post in threaded view
|

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

Brian Inglis
On 2020-11-19 03:03, Kristian Ivarsson via Cygwin wrote:
>>> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin <[hidden email]>:
>>> 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)

>>>>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32

>> 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 might be totally wrong, so does anyone have any take on this ?

Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core,
mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and
djgpp-binutils, mingw64-i686-binutils, mingw64-x86_64-binutils,
cygwin32-binutils, cygwin64-binutils so anyone has the freedom to choose to
build DOS, Windows, or Cygwin apps targeting their respective APIs, under
Cygwin, and also have the freedom to give away or sell those apps as long as
they respect their licences.

Cygwin's goal is to have everyone and everything believe it is running in a
POSIX environment and provide interoperability within a Windows environment
(including Wine) based on POSIX standards, system interfaces, toolchains,
shells, utilities:

        https://pubs.opengroup.org/onlinepubs/9699919799/

system and network servers and services, plus GUI desktops (GNOME, KDE, LXDE,
MATE, Plasma, Xfce desktops on X Window System), and apps (task and file
managers, web browsers, PDF viewers and editors, graphics viewers and editors
including GIMP). This is all ported and supported by volunteers who believe
everyone should have a choice, even when for business or family reasons they use
Windows.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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
Reply | Threaded
Open this post in threaded view
|

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

Eliot Moss
In reply to this post by Cygwin list mailing list
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.)  The behavior I would _expect_ is that the
Cygwin version will work using Posix sorts of assumptions.  While a root of C: (for example) _might_
work, /cygdrive/c is more normative on Cygwin.  (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.

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 "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.

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
Reply | Threaded
Open this post in threaded view
|

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

Cygwin list mailing list
> 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

--
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
Reply | Threaded
Open this post in threaded view
|

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

Cygwin list mailing list
In reply to this post by Brian Inglis
[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
> >> cygstdc++ that
> >> library (cygstdc++) ?


> > I might be totally wrong, so does anyone have any take on this ?
>
> Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core,
> mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp-
> binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32-
> binutils, cygwin64-binutils so anyone has the freedom to choose to build
> DOS, Windows, or Cygwin apps targeting their respective APIs, under
> Cygwin, and also have the freedom to give away or sell those apps as long
> as they respect their licences.
>
> Cygwin's goal is to have everyone and everything believe it is running in
> a POSIX environment and provide interoperability within a Windows
> environment (including Wine) based on POSIX standards, system interfaces,
> toolchains, shells, utilities:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/
>
> system and network servers and services, plus GUI desktops (GNOME, KDE,
> LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and
> file managers, web browsers, PDF viewers and editors, graphics viewers and
> editors including GIMP). This is all ported and supported by volunteers
> who believe everyone should have a choice, even when for business or
> family reasons they use Windows.

Tnx Brian

I think The Cygwin-community is doing a great job but with some caveats, such as this

We're in need of various posix-libraries and I guess they won't be available if using the mingw-g++/libstdc++ (I guess cygstdc++ is needed then due to some special memory models etc etc etc) ?

I can for sure try it out, but that would be quite cumbersome because the and I guess it'll be a whole lot of hazzle to make it working

I'd rather help out or having a dialog of how to fix std::filesystem, i.e. change the usage of the __CYGWIN__ macro in that implementation, but this seems to be a part of the "real" GCC-distribution o I guess I need to be involved in that open-source-community instead, but I guess it somehow is invoked from this project somehow so I guess some people here do have some real insights about this ?

The whole C/C++ community is striving for total cross-platform libraries (but I guess we have a few years left for that) and std::filesystem was supposed to take us all in that direction and I totally understand that std::filesystem-library in Cygwin do think it is on a posix-filesystem (though it's not) and I totally understand why the behaviour is as it is, but I don't agree that is a good thing, considering that the underlaying posix-implementation already today accepts Windows:ish-like-paths in some circumstances, I'd like the whole package to be even more agnostic because most applications don't have any wish to inspect the content of a path-object no more than the value of a socket-descriptor

Applications might wanna extract type, name, parent-folder, etc but do rarely care about what kind of separator it has (/ or \) and the style of the root directory etc and it would be very neat if the cygwin std::filesystem-library became more agnostic in these regards

Best regards,
Kristian


> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains too much
> technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> 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

--
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
Reply | Threaded
Open this post in threaded view
|

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

Brian Inglis
On 2020-11-20 02:37, Kristian Ivarsson via Cygwin wrote:
> [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 cygstdc++ that library (cygstdc++)?

>>> I might be totally wrong, so does anyone have any take on this ?
>>
>> Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core,
>> mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp-
>> binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32-
>> binutils, cygwin64-binutils so anyone has the freedom to choose to build
>> DOS, Windows, or Cygwin apps targeting their respective APIs, under
>> Cygwin, and also have the freedom to give away or sell those apps as long
>> as they respect their licences.
>>
>> Cygwin's goal is to have everyone and everything believe it is running in
>> a POSIX environment and provide interoperability within a Windows
>> environment (including Wine) based on POSIX standards, system interfaces,
>> toolchains, shells, utilities:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/
>>
>> system and network servers and services, plus GUI desktops (GNOME, KDE,
>> LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and
>> file managers, web browsers, PDF viewers and editors, graphics viewers and
>> editors including GIMP). This is all ported and supported by volunteers
>> who believe everyone should have a choice, even when for business or
>> family reasons they use Windows.

> I think The Cygwin-community is doing a great job but with some caveats, such as this
>
> We're in need of various posix-libraries and I guess they won't be available
> if using the mingw-g++/libstdc++ (I guess cygstdc++ is needed then due to
> some special memory models etc etc etc)?

Unlikely - the (cross) tools handle the memory model differences.
There are 400 mingw64 cross-development library and tool packages available for
*each* architecture under Cygwin?

> I can for sure try it out, but that would be quite cumbersome because the
> and I guess it'll be a whole lot of hazzle to make it working

> I'd rather help out or having a dialog of how to fix std::filesystem, i.e.
> change the usage of the __CYGWIN__ macro in that implementation, but this
> seems to be a part of the "real" GCC-distribution o I guess I need to be
> involved in that open-source-community instead, but I guess it somehow is
> invoked from this project somehow so I guess some people here do have some
> real insights about this ?

> The whole C/C++ community is striving for total cross-platform libraries (but
> I guess we have a few years left for that) and std::filesystem was supposed
> to take us all in that direction and I totally understand that
> std::filesystem-library in Cygwin do think it is on a posix-filesystem (though
> it's not) and I totally understand why the behaviour is as it is, but I don't
> agree that is a good thing, considering that the underlaying
> posix-implementation already today accepts Windows:ish-like-paths in some
> circumstances, I'd like the whole package to be even more agnostic because most
> applications don't have any wish to inspect the content of a path-object no more
> than the value of a socket-descriptor
>
> Applications might wanna extract type, name, parent-folder, etc but do rarely
> care about what kind of separator it has (/ or \) and the style of the root
> directory etc and it would be very neat if the cygwin std::filesystem-library
> became more agnostic in these regards
Not a goal of this project, which is to provide Unix look/feel at all levels.
Other projects have the goals of being cross-platform toolkits which you can use
to work and/or look native and hide all differences; see:

https://en.wikipedia.org/wiki/Cross-platform_software#Cross-platform_programming_toolkits_and_environments

Which cross-development libraries/tools are you missing from the 400 mingw64
cross-development library and tool packages available for each architecture
under Cygwin?

You could probably use cygport to easily build any for mingw that are not yet
available in the distro.

You could also do all this on any Linux distro that offers Wine, and natively
under some (especially Fedora/CentOS/EPEL/RHEL) that offer mingw packages, and
even use cygport to do the builds:

        https://repology.org/projects/?search=mingw

where one of those distros shown is Cygwin.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]


--
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
Reply | Threaded
Open this post in threaded view
|

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

Cygwin list mailing list
[snip]

> > Applications might wanna extract type, name, parent-folder, etc but do
> > rarely care about what kind of separator it has (/ or \) and the style
> > of the root directory etc and it would be very neat if the cygwin
> > std::filesystem-library became more agnostic in these regards
> Not a goal of this project, which is to provide Unix look/feel at all
> levels.

Well, "this project" have already introduced some understanding of Windows-paths such as ("C:/" etc)


> Other projects have the goals of being cross-platform toolkits which you
> can use to work and/or look native and hide all differences; see:
>
> https://en.wikipedia.org/wiki/Cross-platform_software#Cross-
> platform_programming_toolkits_and_environments
>
> Which cross-development libraries/tools are you missing from the 400
> mingw64 cross-development library and tool packages available for each
> architecture under Cygwin?



Well, some standardized things for networking, ipc-messaging, multiplexing and such is what's missing in the C/C++ standard but we're not missing anything among libraries and tools in the Cygwin package per say

Our main target is the *nix world and thus "Unix look/feel" is exactly what we like and Cygwin seems to offer a "Unix look/feel" to run our code natively on Windows as well but this "Unix look/feel" doesn't always work in Windows and fails to assimilate that "Unix look/feel"


[1]   std::filsystem::path path{some_path_from_somewhere};
[2]   if(std::filesystem::exists(path))
[3]   {
[4]      auto canonical = std::filsystem::canonical(path);
[5]   }


The code above is very much "Unix look/feel" but the behaviour in Cygwin is not "Unix look/feel" because it might fail on line 4 (complaining that path is not a valid file despite it said so in line 2)


Best regards,
Kristian

> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains too much
> technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>
>
> --
> 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

--
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
12