X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 5020D389683C
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1606210347;
	bh=AaqY6D5ut0qPLpARFCdX03Pr3lzZBWWEP3WZTBEblU4=;
	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=FHLJJ5dBO2VYYE4R6qcJn9+q4AK3b+3ij91RuLZOroaoA1ZrvXpCAhtRyQTwmlEAn
	tU9ViPYz4Oxre9jDmRK+Z/HP3xFvL9nuKNCqSQKEr95VhJwfngs4QmQohiZgAWU/K4
	ZpzhPm70opFv8AbNqWb3SZiOzK8ez3/Y96EabNXI=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org DD474389683F
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=jlAaESS4lV2LmvrA0IQ9kLV4uAras7AYYJIrwFsDFXI=;
	b=JQOrH8pl0kIfjCMocay2ONx9aF0qCNzQ1JTHMgSkUufg5K0J56MA5sKx0bwGX+7ULj
	4RD4CBGz1a7YKuAdNqyG2F8gR2c+i+5W3Ik9e+IjFCH357dZp3xIIlciF5Vk7yTJA2CV
	7KaIlu8WJRl1xWlhGJ33JWSNLfe2+PJpLAzl8L7OYuAck0K5DwJbjTPOs04iVML3yjqN
	4uIN3Bzc1YrFJ/gw9ufgpZTttmPk0ipkHmV1nAimGoDJGjUlhJy10CokNEbwYUojNkqz
	T6CUe/uGNBc1B5Y2P5PoF4vxhCUjeCgN7VtqXPzYmSpDIHYQXqmPXjW/NkWC9Uubttnk
	nfxA==
X-Gm-Message-State:	AOAM531anUNdaoHBgtTEB+vkGXPomDGOFy6ijyXwvDgfRzJ3DrYVco32
	3Et2UTyCIbZlQFDqQLuFf04=
X-Google-Smtp-Source:	ABdhPJxRR5EkWZIdSXNlfdXgCP2QgTQuZeUCCAVEY2EcjG3PeK5V4PDMJk+FByDADY5HxOgraWAujw==
X-Received:	by 2002:ac2:5462:: with SMTP id e2mr1497281lfn.552.1606210343126;
	Tue, 24 Nov 2020 01:32:23 -0800 (PST)
To:	"'Jonathan Yong'" <10walls AT gmail DOT com>,
	"'The Cygwin Mailing List'" <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>
	<000201d6bf17$7cc4beb0$764e3c10$@gmail.com>
	<9e881c01-e883-ecd5-883a-e1ac55c740c7 AT gmail DOT com>
	<000601d6c173$aa55d540$ff017fc0$@gmail.com>
	<d8a72610-a79b-0387-e52b-25f0b50c46ef AT gmail DOT com>
In-Reply-To:	<d8a72610-a79b-0387-e52b-25f0b50c46ef@gmail.com>
Subject:	Sv: Sv: Sv: Sv: g++ and c++17 filesystem
Date:	Tue, 24 Nov 2020 10:32:22 +0100
Message-ID:	<000a01d6c244$b64bbd70$22e33850$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3PghxQI7mYCPAhTJa9sCXpfa/AHDfHWzqPhYgdA=
X-Spam-Status:	No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 0AO9WsxR015850

> On 11/23/20 8:35 AM, sten DOT kristian DOT ivarsson AT gmail DOT 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 beg to differ. My claim was that all the std::filesystem implementations I've seen for Windows, except Cygwin, handles both '\' and '/' and that was my point (Cygwin handles it in some circumstances) so that point is perfectly valid

I'm not considering either '/' or '\' in the code. I'm working with a path. I don't care what kind of separators the path handled to the application have. I want std::filesystem to work properly even if the folder-separator in current platform is ¤#¤#¤#¤

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

I think you have misunderstood my point completely. I know that they are unreliable and that's what I'm trying to have a discussion about, because I cannot see why it has to be unreliable and how it not could be fixed

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

About the code, that's exactly as I stated 

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

Did I get a question about where I think that POSIX requires backslashes or did I make such claim ? If one of them, I have missed that question and I have certainly not made any such claim

All I'm saying is that I'd like std::filesystem in Cygwin to work properly and I still cannot see why that cannot happen ?

What would the drawbacks be if std::filesystem worked more transparent (i.e. correct) and made Cygwin more useful ? I don't think the community would shrink !

Kristian




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