X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org CF0BF38618DF
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1606129767;
	bh=O9w969HzPiQZqqIPZVe2N7kToE93HwqhmLaaioIIw7Y=;
	h=To:References:Subject:Date:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=H0JPFNm6nUnSrQpPQCxNC/zyKMA6e9RDZuCK2I83dbiluy/J9Yy0Gro7M+Aou9k7e
	A9yGQFhhvDdYEU9VaLLShJD+a0gGR6VxYb8A2wi13T5AUFv2Itebfz2bJAYB26txIF
	znKx5EUZRavIiICzc9nSUy6Fr4MUGs0LN9huBd/w=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 730923854819
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:to:references:from:cc:subject:message-id:date
	:user-agent:mime-version:in-reply-to:content-language
	:content-transfer-encoding;
	bh=JLcTgcg0amvEJRm9X9UNJ8Hg7o4Jy5cyK+FCgCMTlrw=;
	b=n0QlaZQ7aGCiK0VO6Yj6iVIQ9oaqLacwJy5VrWhizQVzFeDYnz0BPFzN5CIVO34HoA
	fmV4q/Hy73IYwYbCzwtPT/bTBigz+fc0lN8zrxq7MEaWYqT16lgI21UAK9WSXYg1RSgN
	qrWIlONiNyfcBE9Q9Z7/YMcgF6PA9B7kykbFSbgds2lVcg37lkd+gqcUqfGcLxlxznoj
	TYVW+13LWC6gCjLc66sWcFC/EuBHubLukseGlL3/h5u6orSvFucz5I7krKoIZysQ0JLW
	EV5FHsx1zzUS8ijyV0sQDMziPpcAXBNNi9nS0/2qxpGd8bPkZ2psuIvL+hCiQmZ07S5R
	47Cg==
X-Gm-Message-State:	AOAM531vy43rMEuGSs+XRgpgoJTH4ehMVBPh+9/1dn5dxCm96tfHODfz
	ysT7ruNl1yT8iLT2Eq4n2Iw=
X-Google-Smtp-Source:	ABdhPJw9/mJebdUBGUPrBT0iQPi3itzD5wMqG4n8rb3ytzEdA3DK2+KJ4Sbi87vROFCfD3TOBwgwjA==
X-Received:	by 2002:a63:5262:: with SMTP id s34mr27180089pgl.382.1606129764633;
	Mon, 23 Nov 2020 03:09:24 -0800 (PST)
To:	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>
Subject:	Re: Sv: Sv: Sv: g++ and c++17 filesystem
Message-ID:	<d8a72610-a79b-0387-e52b-25f0b50c46ef@gmail.com>
Date:	Mon, 23 Nov 2020 11:09:16 +0000
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
	Thunderbird/78.4.2
MIME-Version:	1.0
In-Reply-To:	<000601d6c173$aa55d540$ff017fc0$@gmail.com>
X-Spam-Status:	No, score=-3032.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A,
	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-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>
From:	Jonathan Yong via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jonathan Yong <10walls AT gmail DOT com>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

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