g++ and c++17 filesystem

Kristian Ivarsson sten.kristian.ivarsson@gmail.com
Wed Nov 18 20:46:25 GMT 2020

> 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
>> 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).
> 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,

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

More information about the Cygwin mailing list