From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 854A338708B2 for ; Wed, 25 Nov 2020 08:30:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 854A338708B2 Received: by mail-lj1-x22b.google.com with SMTP id j10so1389630lja.5 for ; Wed, 25 Nov 2020 00:30:51 -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=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) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id o130sm167231lff.277.2020.11.25.00.30.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 00:30:49 -0800 (PST) From: To: "'Ken Brown'" , , "'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> <237eacd5-a1bf-da6a-2ee6-f2df945f125b@cs.umass.edu> <000501d6c26e$73e1d760$5ba58620$@gmail.com> <11a20f55-46db-c9b4-1f30-d2181a3aeb9e@cornell.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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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@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: Wed, 25 Nov 2020 08:30:53 -0000 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