From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) by sourceware.org (Postfix) with ESMTPS id CCEF53857C7B for ; Wed, 25 Nov 2020 00:23:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CCEF53857C7B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id hiapknZLrbYg3hiaqkUbp4; Tue, 24 Nov 2020 17:23:32 -0700 X-Authority-Analysis: v=2.4 cv=Q4RsX66a c=1 sm=1 tr=0 ts=5fbda404 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=szdCxXGuq2pOcHchTsQA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com 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> From: Brian Inglis Organization: Systematic Software Subject: Re: g++ and c++17 filesystem Message-ID: Date: Tue, 24 Nov 2020 17:23:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <000501d6c26e$73e1d760$5ba58620$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfNN62KbjSABzMeV7qSPdGTxk/+yeqDMg5gEVnQbgSVJeIp3QNRlSCObVGkqXS0F3Bz0fC15GHldsdijtrz2uvalOuS7yZ4OZwW3QUCFK1QscQNyM7+rz rb9PujHRzymv4u974JEQvbQRM9jNpplz2/KoGwQAXWhcEOafD0BcLfBWVgWj7YV1IJEW8Hqw7SQYj0zw98DDx7R/eJ0/Brel3kk= X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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: Wed, 25 Nov 2020 00:23:35 -0000 On 2020-11-24 07:31, Kristian Ivarsson via Cygwin wrote: >> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: >> >>> 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) ? Nobody is interested in doing the work to submit and modify patches to get them accepted and change it from the way it is. > 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) If you only use POSIX compliant Cygwin or UNC (//) paths, all your programs built under Cygwin should run successfully under Windows or Wine. Otherwise if you built under Cygwin, you can overload your directory and file path methods so if a path contains : or \\ you call cygwin_conv_path() with appropriate flags to fix your path before using it. Or build with Mingw or MSVC++ and use whatever those allow. Cygwin is an open source project maintained solely by volunteer contributors in their spare time, and its focus is on working around Windows limitations to provide a POSIX standard environment and experience, supporting more POSIX features as Windows limitations are removed. Other projects gcc-g++, libstdc++ may have sponsored or employed contributors. They all have their respective standards focus and are uninterested in non-standard-compliant changes and any non-POSIX build changes. But they build and run just fine under Cygwin. Feel free to make the appropriate patches to the components and submit the patches to the upstream projects. But be prepared for the upstream projects to reject the patches if they break some standard or compliant test case or use case. Note that it has taken Intel and then MS five years to get FSGSBASE support patches accepted in Linux. If you are unprepared to do the necessary work, you still get a lot more than what you paid for. ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]