From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id C8A9D385040C for ; Tue, 24 Nov 2020 14:01:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C8A9D385040C Received: by mail-lj1-x22d.google.com with SMTP id t22so9741503ljk.0 for ; Tue, 24 Nov 2020 06:01:16 -0800 (PST) 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) Received: from JOKK (static-213-115-54-10.sme.telenor.se. [213.115.54.10]) by smtp.gmail.com with ESMTPSA id m20sm1736653lfc.172.2020.11.24.06.01.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 06:01:14 -0800 (PST) From: To: "'Jonathan Yong'" <10walls@gmail.com>, "'The Cygwin Mailing List'" References: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu> <000201d6bf17$7cc4beb0$764e3c10$@gmail.com> <9e881c01-e883-ecd5-883a-e1ac55c740c7@gmail.com> <000601d6c173$aa55d540$ff017fc0$@gmail.com> <000a01d6c244$b64bbd70$22e33850$@gmail.com> <001801d6c255$f0e115a0$d2a340e0$@gmail.com> <2d906235-e206-f6c6-5302-9b11bbe484c7@gmail.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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 14:01:18 -0000 > > [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 > > >=20 > 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 >=20 > 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?=20 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=20 > 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