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

- Raw text -