X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F278385700F
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=cs.umass.edu
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=moss AT cs DOT umass DOT edu
Subject: Re: Sv: g++ and c++17 filesystem
To: cygwin AT cygwin DOT com
References: <c2d6280c-26e3-f9e7-89bd-693385a768b2 AT gmail DOT com>
 <D3704C33-A283-40F0-990D-CB9806F0B09D AT gmail DOT com>
 <000a01d6be5b$3808cad0$a81a6070$@gmail.com>
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID: <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu>
Date: Thu, 19 Nov 2020 10:36:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <000a01d6be5b$3808cad0$a81a6070$@gmail.com>
Content-Language: en-US
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 LIKELY_SPAM_BODY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To: moss AT cs DOT umass DOT edu
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

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