X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 5F8EE3857807
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1605861074;
	bh=J8SUIW3iVEQknfd092kjtanSmiXhjc/6/+jiLp+mLwE=;
	h=To:References:In-Reply-To:Subject:Date:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=fG/UXyn0N8hbo5mXum5fSqpiPFc6dZ1Xg6jeVXfUwjC267ay4X4jKOkh+Ni6HjluM
	LdZL3PdaZo0ty4vhiDErgfuU19YETKH+m59eXOdIdYsY8m2fdQpLDis1iKe8SUssnG
	a0RXzvffURYvdkXBt7tAFNW2x3x3uAmnG273Nn0Y=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 3422F3857807
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-transfer-encoding:content-language
	:thread-index;
	bh=l4vLRSbxpekJKhozlzBlTZKoGiXCyVstdrKzVEWIhG4=;
	b=djb36CcyOXHWgj4p3HnkV4g+QZQ47369LDRulFW0ye7QR7vm1IA1VJXLIZoTbyUVxp
	Xal4v8cU7U7lgJOD9SVeIZXUWFmd0MmJDvKzCMguxKWQmMixaEVTuXSr37z72PnExHhP
	X+2Go49dCjgy9Rgej5Dj7nXBo+ei1eam2Jhu2ABVCTPgaQevIpXhNWqKdeVZ8dDzuxRz
	wZL6iZMg7OOM1ovXBVK3Qz9IBO122ooXKJw1mFVReivVSg0hsEq0n1jjpsg8Ks5V0IqW
	e2BCLgHlCduK1m9oZB3AnYr/QMu7ozOQMxmSo5eETZ9kNVMshZnCZIb0GsFSXb1IYtSM
	jp9A==
X-Gm-Message-State:	AOAM530LH2A6D3LDDpSJvlTEEE5dNhQjMnzgx9EIcsKM2NXeZL3aPKhs
	OjP9N3sesMUAtxNr16b7r/KH48rs5K0=
X-Google-Smtp-Source:	ABdhPJwHgtboeDJGb2M7yYCWoMDLYPvYlgj6Bn/wXLK4lN/IDu+UIbNaAQ4g7G6yZR0ixdPPKZO87A==
X-Received:	by 2002:ac2:43a4:: with SMTP id t4mr7277056lfl.8.1605861065813;
	Fri, 20 Nov 2020 00:31:05 -0800 (PST)
To:	<moss AT cs DOT umass DOT edu>, <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>
	<87a2c99c-045c-e815-4c03-bab7a89a025b AT cs DOT umass DOT edu>
In-Reply-To:	<87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu>
Subject:	Sv: Sv: g++ and c++17 filesystem
Date:	Fri, 20 Nov 2020 09:31:04 +0100
Message-ID:	<000201d6bf17$7cc4beb0$764e3c10$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3Pghxak1ldwg
X-Spam-Status:	No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, LIKELY_SPAM_BODY,
	RCVD_IN_DNSWL_NONE, 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-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>
From:	Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	sten DOT kristian DOT ivarsson AT gmail 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.)

At least semantic bugs considering the whole concept

> The behavior I would _expect_ is that the Cygwin version will work using
Posix sorts of assumptions.

I guess it will to, but then your application have to ensure that in every
place the application uses a file path and the reasons we do have
(platform-independent) libraries is to not having to do that

> While a root of C: (for example) _might_ work, /cygdrive/c is more
> normative on Cygwin.

Yes, but to what purpose ? What applications do explicitly handle any root
directory (except for possibly /tmp or /dev/null) ?

(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

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)

> 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

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

As stated earlier, we're using Cygwin to be able to keep some kind of cross
platform code base and Cygwin offers non-cross-platform-standardized
libraries/api:s (i.e. posix) to be executable without having to #ifdef the
code base to be buildable and executable on Windows but MinGW doesn't supply
those posix libraries on Windows (maybe a few), so using GCC/MinGW is not an
option and I guess we'd go with MSVC if we wanted to port our code
completely

std::filesystem is supposed to be cross-platform (and easier to use than
various posix-library-C-functions) though and it is cross-platform per
definition but, then again, not when using Cygwin

> 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

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