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

Jonathan Yong 10walls@gmail.com
Wed Nov 25 02:25:07 GMT 2020


On 11/24/20 2:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>> [snip]
>>>
>>>> std::filesystem POSIX mode is common to all POSIX platforms where
>>>> backslashes are NOT directory separators. How do you make them accept
>>>> your demands? How are you going to force POSIX platforms allow
>>>> Windows specific code?
>>>
>>> I've been trying to say over and over again that our code doesn't
>>> handle any Windows specific stuff and not anywhere have I claimed that
>>> anyone else need to handle Windows specific stuff either (except for
>>> the internals of Cygwin of which Windows specific logic is already
>>> present)
>>>
>>> I repeat; I don't expect any of the Cygwin-Posix-functions to accept
>>> any Windows-style-paths (though some of them, as I repeatedly have
>>> said, already does so) and I only expect that I can operate according
>>> to the C++-standard on an instantiated std::filesystem::path
>>>
>>
>> How do you expect std::filesystem to do that when Windows paths are not
>> even accepted in API calls?
> 
> What API-calls ? Cygwin-Posix-API-calls ? If so, you assume that std::filesystem in Cygwin must be implemented using the underlaying Cygwin-Posix-API and maybe it must be of some reason, but I guess it even would be possible to make it the other way around, i.e. quite a bunch of the Cygwin-Posix-file-API-functions could be implemented by using some native std::filesystem-implementation such as MinGW but I guess that not the whole Cygwin-Posix-file-API could be implemented that way and it would probably be some quite substantial rewrite of things that probably is not worth the effort, but what I'm trying to say is that std::filesystem shipped with Cygwin not necessarily have to be implemented totally with the underlaying Cygwin-Posix-API. It could be a mix to use whatever is appropriate and in some circumstances some logic is needed to understand both kind of paths
> 
> 
> See more below
> 
> 
> 

No, std::filesystem runs on top of Cygwin, not under it, it would have 
to use POSIX APIs to get anything done. GCC is not the platform system 
library.

>>>> Make it try to enter subdirectories every time std::filesystem is
>>>> called?
>>>>
>>>> You refuse to understand that Cygwin is NOT Windows, it is a POSIX
>>>> platform. Using Cygwin means complying with POSIX expectations and
>>>> standards.
>>>>
>>>> I don't see how this conversation can continue if you still refuse to
>>>> see Cygwin as something separate from Windows. Besides, you have
>>>> already answered your question by ruling out MinGW, so Microsoft
>>>> Visual Studio it is.
>>>
>>> I repeat (again); neither MinGW/MSVS is an option because we're trying
>>> to use Posix and C++
>>>
>>> Just to be clear:
>>>
>>> - Our code DOESN'T handle Windows-style-paths explicitly in any way
>>> - We DON'T expect Cygwin-Posix-file-related-functions to accept
>>> Windows-style-paths
>>> - We WOULD like std::filesystem to work according to the C++ ISO
>>> standard
>>
>> Why would std::filesystem be an exception? How would it know if a
>> backslash is part of a name and not a separator? How does it know when to
>> apply exceptions? What about mixed paths?
> 
> As I've said before, there are already exceptions. Some Cygwin-Posix-mechanisms already understands both kinds of path's today
> 
> How are '\' handled as part of the name today ? I works perfectly well in many circumstances, so I guess that there are quite a few exceptions already
> 

Its not able to read your mind to find out your intentions, especially 
when it comes to ambiguous strings like UNC or SMB paths, none of these 
are remotely POSIX compliant.

>> The C++ standard mentions separators, not specific characters, and the
>> forward slash is used under Cygwin, not the Windows backslash.
> 
> Exactly, I haven't stated anything else
> 

So use the forward slash, not backslash.

>> The bigger question would be how would you expect a Cygwin application to
>> even accept a Windows paths. It should use *nix paths, as all Cygwin
>> programs do
> 
> Cygwin (and thus applications build within Cygwin) already do accept Windows paths here and there as well as std::filesystem
> 

It does not. There are giant warnings telling you not to rely on it.

> Applications don't have control of all the input that could come from UI, environment, configuration, etc
> 

Garbage in, garbage out. The warnings tell you to use Unix paths.

> What I'm trying to make a point of is that wouldn't it be good if applications didn't have to care about that, because that is what libraries/frameworks are for, to give an abstraction ?
> 
> Otherwise every application have to do something like where ever it handles some path
> 
> #ifdef _CYGWIN_
>     // fix the path-representation to something with /cygdrive or such
>     ...
> #endif
> 

Why? Cygwin is a POSIX system. The prefix isn't even necessarily 
/cygdrive and you're just introducing more complications that falls 
apart the moment the defaults change.

> This is what we're hoping to avoid to do and that it could be done in the library we're using
> 
> The exact details of how to implement this and what challenges that would be is uninteresting before it could be settled as "Yeah, it would be a good feature to let std::filesystem to be path-style-agnostic"
> 
> C++ applications do mostly use std::filesystem, std::ofstream, std::ifstream and do not mix that with Posix-file-mechanisms, but for Cygwin, /cygdrive/... in std::filesystem must of course be a valid path as well
> 
> 

The C++ standard library APIs are wrappers around the Cygwin APIs like 
open(3) and write(3), so a Windows path there would still fail. Just 
because it comes from the C++ standard library, doesn't mean its 
magically separated from the underlying system.

> I can't stress this enough and point out that this community have already decided to here and there make Cygwin be Windows-style-paths-aware, so I cannot see that it would be that of a bad idea if it became even more agnostic to what kind of path is used, but of course I understand it comes with some challenges
> 

No, Windows paths are not supported, merely working as a side effect. 
Are you going to demand POSIX compliant scripts to also handle Windows 
paths next?

> 
> p.s.
> 
>     We do have an open source product targeting the *nix-world as well and at the same time we're trying to make it runnable on Windows, so this is not just me be being stubborn
> 

But Cygwin is NOT Windows, you still refuse to accept this fact. Cygwin 
programs have no reason to act as Windows applications, Cygwin programs 
act like Cygwin programs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Type: application/pgp-keys
Size: 7929 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20201125/8e41c66c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20201125/8e41c66c/attachment.sig>


More information about the Cygwin mailing list