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

[Jonathan Yong <10walls@gmail.com>]

On 11/23/20 8:35 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
>>>> 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)
>>>
>>
>> That is not correct, \ is a valid filename under *nix, but not on Windows.
>> I don't think the standards specify what filenames or character sets are
>> valid. Cygwin strives for *nix compatibility, anything else is secondary.
> 
> 
> I should have made my point clear; "All the implementations of std::filesystem for Windows ..."
> 
> 

That is an incorrect understanding, Cygwin is NOT Windows, it is its own 
platform, you should not consider it even Windows unless you are working 
on Cygwin internals.

>>>> 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
>>>
>>
>> Cygwin is not Windows, it runs on Windows, but it is not Windows. You
>> should use mingw if you want Windows style paths. There isn't a magical
>> tool that allows you to have it both ways.
> 
> As I'm trying to say, Cygwin already accepts Windows-style-paths in some circumstances and thus it have SOME magic, so why not extend that and thus make it easier to use Cygwin on its target platform, i.e. Windows ?
> 

Because libstdc++ is not part of Cygwin, it is part of the GCC project, 
developed by completely different developers. GCC runs on Cygwin, so it 
is expected to use standard *nix API, not windows. Windows path 
conversions are entirely unreliable, see the mess that is MSYS, when 
Windows and *nix paths collide.

> As I've said, to use MinGW along with Cygwin would be very tricky without bumping into ODR/memory issues
> 
> I don't think MinGW alone give us enough support alone to keep our code base non platform specific (*nix+windows)
> 
> 

If you are on Cygwin, use *nix APIs and paths, that's the end to it. You 
should not mix Cygwin compiled code with MinGW.

>>
>> Yes, cross platform, you can use std::filesystem on Linux, Cygwin,
>> Windows, Macs, but it certainly cannot do anything that can't be handled
>> for the underlying platform. For Cygwin, it means using *nix paths, not
>> Windows.
> 
> Exactly, so why obfuscate the underlaying platform with a Posix-layer that also can do exactly just what the underlaying platform can and then back to some standard interface again (i.e. std::filesystem) which make a roundtrip that only can result in loss of information/functionality ?
> 

Because Cygwin is exactly that, to emulate POSIX layer on Windows, if 
POSIX mandates exposing Windows paths, then you would see Cygwin 
reworked to support it.

> I rather have a dialogue of how that that could be done rather than "Cygwin is *nix, deal with it" or at least it would be nice to hear if someone do have some insightful thoughts of why it must the way it is or why it would be so hard to make parts (e.g. std::filesystem) more useful ?
> 
> 

That's not what Cygwin is for, you ignore everything while conveniently 
claiming to be looking for "insightful thoughts". You still haven't 
answered where is it in the POSIX standard requires backslashes to be 
used as separator or how are you going to make other *nix platforms 
accept such a change?