X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 48848393D030
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1606226479;
	bh=lXxbp/nQNZq1OLCQLDQ03XkXhIPzddSERdGiPvKZiG8=;
	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=UXlk7hcFTKqZjLOIGe9Ssi7CKmL63bV0EgkNXf84/S2c/jgDLIkBYUjSBuij4UZvM
	WbBIW9rogeaHkOhpdKGTP8sVNfjuoHkIBf1WT2KMYKzH6xOooX5mLT+wOM22wIKSPN
	7Tgo3Kw6s8xn+trpYEZRbqmRt4R7e57XLJG7mL9s=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org C8A9D385040C
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=6xzZn52rEjK3i/ZPDb+o9PtQGaTR5K53TzWb6qN3oSM=;
	b=l2zzUAYl2b+hLmECrzrFMLjiB2sMqSergCi7kDY5Xq/owW1Msnjj1UQk76Xg+rzbXf
	PbIyn3MDvth2cNDMDFP+3kMnjNnaCKCVmtsaMBgYuz5D2H0n04em+9JCWXiwhC0ZEI9A
	/qqC9WIuJ7LesX7ku9vBBffNS/2Dy2bGf90C7VFU81kDobJP4pQHARGyRtuBE7MKWQhH
	OyEQVTOhb77FYgk9lQWD/hoed80ttV17O1+djmmiR3wvgTBu2o9vU+khsUBX8FplOXE2
	lagZVAfWX7q/CJRhEGka7XZyQimjr2K9LGCkjaX803vGQLrQuyYjbDPVGFlxdrR3WOGs
	ugNA==
X-Gm-Message-State:	AOAM532XuGoPde4gDdPUe04FhXCOGs1GO9CUKzpzDCRolp0A/8BtaGoP
	sfRTy2oVPyoY21bK0pCBrfo=
X-Google-Smtp-Source:	ABdhPJzIqlkwwwMOkfpx1kt3zs21LWl8wDZA94SsstRLgSrKgqdEqI75gnK4iNgb/x+DyGCsalGFsQ==
X-Received:	by 2002:a2e:9f55:: with SMTP id v21mr1998785ljk.288.1606226475332;
	Tue, 24 Nov 2020 06:01:15 -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>
	<000a01d6c244$b64bbd70$22e33850$@gmail.com>
	<ec2a7fe8-35c8-21e5-bb6a-687e7968db53 AT gmail DOT com>
	<001801d6c255$f0e115a0$d2a340e0$@gmail.com>
	<2d906235-e206-f6c6-5302-9b11bbe484c7 AT gmail DOT com>
In-Reply-To:	<2d906235-e206-f6c6-5302-9b11bbe484c7@gmail.com>
Subject:	Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
Date:	Tue, 24 Nov 2020 15:01:13 +0100
Message-ID:	<002d01d6c26a$45931f80$d0b95e80$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3PghxQI7mYCPAhTJa9sCXpfa/AHDfHWzAafgnf4BRx5COwGttY0pASJUSV+oyqknIA==
X-Spam-Status:	No, score=-2.4 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>

> > [snip]
> >
> >> std::filesystem POSIX mode is common to all POSIX platforms where
> >> backslashes are NOT directory separators. How do you make them accept
> >> your demands? How are you going to force POSIX platforms allow
> >> Windows specific code?
> >
> > I've been trying to say over and over again that our code doesn't
> > handle any Windows specific stuff and not anywhere have I claimed that
> > anyone else need to handle Windows specific stuff either (except for
> > the internals of Cygwin of which Windows specific logic is already
> > present)
> >
> > I repeat; I don't expect any of the Cygwin-Posix-functions to accept
> > any Windows-style-paths (though some of them, as I repeatedly have
> > said, already does so) and I only expect that I can operate according
> > to the C++-standard on an instantiated std::filesystem::path
> >
> 
> How do you expect std::filesystem to do that when Windows paths are not
> even accepted in API calls?

What API-calls ? Cygwin-Posix-API-calls ? If so, you assume that std::filesystem in Cygwin must be implemented using the underlaying Cygwin-Posix-API and maybe it must be of some reason, but I guess it even would be possible to make it the other way around, i.e. quite a bunch of the Cygwin-Posix-file-API-functions could be implemented by using some native std::filesystem-implementation such as MinGW but I guess that not the whole Cygwin-Posix-file-API could be implemented that way and it would probably be some quite substantial rewrite of things that probably is not worth the effort, but what I'm trying to say is that std::filesystem shipped with Cygwin not necessarily have to be implemented totally with the underlaying Cygwin-Posix-API. It could be a mix to use whatever is appropriate and in some circumstances some logic is needed to understand both kind of paths


See more below



> >> Make it try to enter subdirectories every time std::filesystem is
> >> called?
> >>
> >> You refuse to understand that Cygwin is NOT Windows, it is a POSIX
> >> platform. Using Cygwin means complying with POSIX expectations and
> >> standards.
> >>
> >> I don't see how this conversation can continue if you still refuse to
> >> see Cygwin as something separate from Windows. Besides, you have
> >> already answered your question by ruling out MinGW, so Microsoft
> >> Visual Studio it is.
> >
> > I repeat (again); neither MinGW/MSVS is an option because we're trying
> > to use Posix and C++
> >
> > Just to be clear:
> >
> > - Our code DOESN'T handle Windows-style-paths explicitly in any way
> > - We DON'T expect Cygwin-Posix-file-related-functions to accept
> > Windows-style-paths
> > - We WOULD like std::filesystem to work according to the C++ ISO
> > standard
> 
> Why would std::filesystem be an exception? How would it know if a
> backslash is part of a name and not a separator? How does it know when to
> apply exceptions? What about mixed paths? 

As I've said before, there are already exceptions. Some Cygwin-Posix-mechanisms already understands both kinds of path's today

How are '\' handled as part of the name today ? I works perfectly well in many circumstances, so I guess that there are quite a few exceptions already 

> The C++ standard mentions separators, not specific characters, and the
> forward slash is used under Cygwin, not the Windows backslash.

Exactly, I haven't stated anything else

> The bigger question would be how would you expect a Cygwin application to
> even accept a Windows paths. It should use *nix paths, as all Cygwin
> programs do

Cygwin (and thus applications build within Cygwin) already do accept Windows paths here and there as well as std::filesystem

Applications don't have control of all the input that could come from UI, environment, configuration, etc

What I'm trying to make a point of is that wouldn't it be good if applications didn't have to care about that, because that is what libraries/frameworks are for, to give an abstraction ?

Otherwise every application have to do something like where ever it handles some path

#ifdef _CYGWIN_
   // fix the path-representation to something with /cygdrive or such
   ...
#endif

This is what we're hoping to avoid to do and that it could be done in the library we're using

The exact details of how to implement this and what challenges that would be is uninteresting before it could be settled as "Yeah, it would be a good feature to let std::filesystem to be path-style-agnostic"

C++ applications do mostly use std::filesystem, std::ofstream, std::ifstream and do not mix that with Posix-file-mechanisms, but for Cygwin, /cygdrive/... in std::filesystem must of course be a valid path as well


I can't stress this enough and point out that this community have already decided to here and there make Cygwin be Windows-style-paths-aware, so I cannot see that it would be that of a bad idea if it became even more agnostic to what kind of path is used, but of course I understand it comes with some challenges


p.s.

   We do have an open source product targeting the *nix-world as well and at the same time we're trying to make it runnable on Windows, so this is not just me be being stubborn

d.s

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 -