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'" , , "'Jonathan Yong'" <10walls AT gmail DOT com>, "'The Cygwin Mailing List'" References:

<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> <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 Content-Language: en-gb 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 List-Archive: List-Post: List-Help: List-Subscribe: , From: Kristian Ivarsson via Cygwin Reply-To: sten DOT kristian DOT ivarsson AT gmail DOT com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Cygwin" 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 /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