From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by sourceware.org (Postfix) with ESMTPS id 6F278385700F for ; Thu, 19 Nov 2020 15:36:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F278385700F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.umass.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=moss@cs.umass.edu Received: from [192.168.0.13] (c-24-62-203-86.hsd1.ma.comcast.net [24.62.203.86]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id 2C29740167EB; Thu, 19 Nov 2020 10:36:39 -0500 (EST) Reply-To: moss@cs.umass.edu Subject: Re: Sv: g++ and c++17 filesystem To: cygwin@cygwin.com References: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> From: Eliot Moss Message-ID: <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu> Date: Thu, 19 Nov 2020 10:36:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Thu, 19 Nov 2020 15:36:40 -0000 Ok, first, I admit that I was not familiar with the details of std::filesystem. However, after looking at it, I remain unsurprised that the Cygwin and Mingw versions might be different. (I would also not be surprised if there is a real bug in there.) The behavior I would _expect_ is that the Cygwin version will work using Posix sorts of assumptions. While a root of C: (for example) _might_ work, /cygdrive/c is more normative on Cygwin. (I put a link to that in Cygwin's / called c, so that, for me, /c works.) Likewise, I would expect the normative path separator to be / not \, and an absolute path to start with /. Windows offers several kinds of symlinks, with varying semantics, so the detailed behavior of that would be affected by the settings in the CYGWIN environment variable. I would expect std::filesystem to present paths to construct paths to present to underlying library calls such as open ... and on Cygwin, open uses Posix style paths. I "get" that you want to write portable programs that use this interface, which is analogous to the Java file path classes. In terms of how this interface works, I would expect it to _claim_ that it is Posix, not Windows, because the paths Cygwin supports are Posix style (it _will_ recognize a few Windows idioms, but it is correct in not advertising itself as Windows). So it you want to do Windows-style (but abstracted with this library), I direct you to Mingw. Each has its place. Cygwin allows one to pretend, pretty successfully though with a few small rough edges, that one is on Linux, not Windows. That is its intent. Mingw gives you the gcc/gnu toolchain and libraries under Windows. I hope we're not still talking at cross purposes, though that it certainly possible! Best wishes - EM