X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 6D105388A400
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1606293054;
	bh=4hJSg+k15oG+HHbRCconNnYfoHjZo2CLW17Y8spsjoA=;
	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=qZNorqqjyTD/Cd7NZCcam0cssSrVI7W/QsHfjUfgAmY57f4xTMN9+HimzNXQI3g76
	X4oA5NCERC1ZkbMly133FfWBJLMly8ryIyeZGat29Vnww5Hb03FbWafR++QZqp16bd
	gvPkjRTdad+wy+D+aWAiPKptnr1oCacOy/KNARPA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 854A338708B2
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=Q7945EGwRtcnel28suq7cCn+SUZzHURCWOTmGvZfTqQ=;
	b=o2/FUxDETwHkTJfHS5QrPJpUhgte11y5kpr2OTBNMnURUk0Ah9I0k04XQF62peTQME
	ja9VLBE98ehZDLJKI5R1KBh7P9aMHQUP+0EjC9il2EQ6LCaJRrx6eA5lryNjaUgS8rVA
	A+aVmr2Pu8QO+9hw6FNShauiw1bzzuFQxE1RkHoUILiQEnv/nIFljgn0RvkMHoc8s9zU
	UsVFWM3VRf3+32d99jbQBXBz0PCuQdhQIpNHBUulkve3XkHZBNgWVKBqrh3jvhvH5zVh
	NNaEiWGyIRCvgK2b9r0AUaCb1nKR1IB1Uqbjq4n2OmgeoT+djoYYdVgehW4biTZ0NnZZ
	PysQ==
X-Gm-Message-State:	AOAM530LqiV/VbETnwaw0y+8oHdOX02s0XRa39MwS8ZYJQaFApP+rb4o
	R9QKRjB/S74LsA8qN/C2yOM=
X-Google-Smtp-Source:	ABdhPJxjo1xGBKlrEchSEKeuOpTvUbI0udPr1UJrooXipb1Xq4c6dQYGM4rrMFVSVlZSvs9VczgdKA==
X-Received:	by 2002:a2e:b0c3:: with SMTP id g3mr897690ljl.287.1606293050248;
	Wed, 25 Nov 2020 00:30:50 -0800 (PST)
To:	"'Ken Brown'" <kbrown AT cornell DOT edu>, <moss AT cs DOT umass DOT edu>,
	"'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>
	<000a01d6c244$b64bbd70$22e33850$@gmail.com>
	<237eacd5-a1bf-da6a-2ee6-f2df945f125b AT cs DOT umass DOT edu>
	<000501d6c26e$73e1d760$5ba58620$@gmail.com>
	<11a20f55-46db-c9b4-1f30-d2181a3aeb9e AT cornell DOT edu>
In-Reply-To:	<11a20f55-46db-c9b4-1f30-d2181a3aeb9e@cornell.edu>
Subject:	Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
Date:	Wed, 25 Nov 2020 09:30:48 +0100
Message-ID:	<002001d6c305$475e8d40$d61ba7c0$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3PghxQI7mYCPAhTJa9sCXpfa/AHDfHWzAafgnf4Bf6X0yAF3M7+8ATG+gL2oy1sVMA==
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>

Thanx for the insightful thoughts Ken

See more below

> >>> all the std::filesystem implementations I've seen for Windows
> >>
> >> The implementation on top of Cygwin is not "for Windows", it's "for
> >> Cygwin", i.e., "for Posix".  And for Cygwin that's the right thing to
> do.
> >> And that's where we keep talking at cross purposes.
> >
> >
> > Maybe it is the right thing to do, but what is your take of why it must
> be so (all the way) ?
> >
> > I also do understand that it have several advantages in the
> > implementation of std::filesystem but it also imply an extra layer of
> > abstraction to the underlaying platform, but to just remove the
> > _CYGWIN_ macro when building it would make std::filesystem to not
> > understand /cygdrive at all (and I guess that would confuse other
> > users;-) so I guess it would require some more sophisticated
> > implementation (or extend the number of exceptions already existing in
> > the underlaying Cygwin-Posix-implementation)
> 
> I'd like to try to make this discussion more concrete by looking at what's
> actually going on in the test program main.cpp that you posted at the
> beginning of that thread.  (I ran it under strace and gdb to see this for
> myself.)
> 
> First, your program calls std::filesystem::exists, which ultimately calls
> stat(2) in the Cygwin DLL.  The work for this is done in the
> path_conv::check function and various functions that it calls.  These
> functions have code that recognizes Win32 paths like C:\Temp, and
> std::filesystem::exists therefore reports "true".  This is consistent with
> the statement at
> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 about how the
> Cygwin DLL treats Win32 paths.
> 
> Next, your program calls std::filesystem::canonical.  This calls
> std::filesystem::absolute, which reports that C:\Temp is not an absolute
> path.
> It therefore tries to treat it as a relative path and fails with "No such
> file or directory" because <current directory>/C:\Temp does not exist.
> Note that the Cygwin DLL never sees the original path C:\Temp in this
> case.  Again, this is consistent with the statement in the documentation
> that Cygwin applications do not necessarily recognize Win32 paths.
> 
> You say this is a bug, because first you're told that C:\Temp exists and
> then you're told it doesn't.  But I think it just illustrates the hazards
> of using
> Win32 paths in Cygwin, which tries hard to emulate Posix.  Sometimes you
> can get away with using Win32 paths and sometimes you can't, depending on
> how and when the Cygwin DLL is involved.

Well, to call it a bug in this context was maybe wrong, but in a
ISO-standard perspective it would be considered a bug ;-)

> I don't see a good way to avoid this inconsistency.  We could change
> Cygwin so that it rigidly recognizes only Posix paths.  Cygwin would then
> be consistent, but we would be removing a feature that many users have
> become accustomed to

I guess so too, but they are already there for some reason

I don't expect that the posix-functions should accept any non-posix-paths
but it would be nice to have the platform independent std::filesystem to
work transparently but I guess, since the cygstdc++-library uses the
underlaying posix-functions the only reasonable way to accomplish this is to
extend the list of features that already exists

The sole reason for std::filesystem was to avoid platform dependent code

So I guess in practical, it is up to the community of how well motivated
they are to extend those Posix-functions but my take in this thread is that
many rather would like it to become more ... like an emulator 

> And it wouldn't help you.  Or we could ask all Cygwin package maintainers
> to try to patch their packages so that they recognize Win32 paths, but
> that's simply not feasible, nor would many package maintainers be willing
> to invest the required time.

I'm not sure what package maintainers you're referring to here now ?
Applications ? Cygwin ? GCC ?

> I tried it once with emacs, which I maintain, in response to a user
> request.  I failed miserably.  Every change I made broke something else,
> and I finally gave up.
> 
> I don't think g++ will be any easier than emacs, and I don't think you can
> expect the g++ maintainer to work on this.

Yeah, I noticed that the _CYGWIN_ macro actually was a part of the real
libstdc++-distro

Thanx Ken and keep up the good work

Kristian

> Ken

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