From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 3422F3857807 for ; Fri, 20 Nov 2020 08:31:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3422F3857807 Received: by mail-lf1-x133.google.com with SMTP id u18so12259657lfd.9 for ; Fri, 20 Nov 2020 00:31:07 -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=l4vLRSbxpekJKhozlzBlTZKoGiXCyVstdrKzVEWIhG4=; b=djb36CcyOXHWgj4p3HnkV4g+QZQ47369LDRulFW0ye7QR7vm1IA1VJXLIZoTbyUVxp Xal4v8cU7U7lgJOD9SVeIZXUWFmd0MmJDvKzCMguxKWQmMixaEVTuXSr37z72PnExHhP X+2Go49dCjgy9Rgej5Dj7nXBo+ei1eam2Jhu2ABVCTPgaQevIpXhNWqKdeVZ8dDzuxRz wZL6iZMg7OOM1ovXBVK3Qz9IBO122ooXKJw1mFVReivVSg0hsEq0n1jjpsg8Ks5V0IqW e2BCLgHlCduK1m9oZB3AnYr/QMu7ozOQMxmSo5eETZ9kNVMshZnCZIb0GsFSXb1IYtSM jp9A== X-Gm-Message-State: AOAM530LH2A6D3LDDpSJvlTEEE5dNhQjMnzgx9EIcsKM2NXeZL3aPKhs OjP9N3sesMUAtxNr16b7r/KH48rs5K0= X-Google-Smtp-Source: ABdhPJwHgtboeDJGb2M7yYCWoMDLYPvYlgj6Bn/wXLK4lN/IDu+UIbNaAQ4g7G6yZR0ixdPPKZO87A== X-Received: by 2002:ac2:43a4:: with SMTP id t4mr7277056lfl.8.1605861065813; Fri, 20 Nov 2020 00:31:05 -0800 (PST) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id i4sm270637lfd.190.2020.11.20.00.31.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 00:31:05 -0800 (PST) From: To: , References: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu> In-Reply-To: <87a2c99c-045c-e815-4c03-bab7a89a025b@cs.umass.edu> Subject: Sv: Sv: g++ and c++17 filesystem Date: Fri, 20 Nov 2020 09:31:04 +0100 Message-ID: <000201d6bf17$7cc4beb0$764e3c10$@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+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3Pghxak1ldwg X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, 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: Fri, 20 Nov 2020 08:31:12 -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.) At least semantic bugs considering the whole concept > The behavior I would _expect_ is that the Cygwin version will work using Posix sorts of assumptions. I guess it will to, but then your application have to ensure that in every place the application uses a file path and the reasons we do have (platform-independent) libraries is to not having to do that > While a root of C: (for example) _might_ work, /cygdrive/c is more > normative on Cygwin. Yes, but to what purpose ? What applications do explicitly handle any root directory (except for possibly /tmp or /dev/null) ? (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 All the implementations of std::filesystem I've seen so far, is agnostic to whether / or \ is used as a path separator (but the generic form is '/' and a fun fact, the MSVC-implementation of std::filesystem handles the generic (posix) form more close to the standard specification than GCC) > 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 consider that to be a mistake in the implementation of std::filesystem, because on Windows the preferred style would be smt like C:/ and then as an opt-out it would consider /cygdrive/c (or such) as a valid thing as well > 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. As stated earlier, we're using Cygwin to be able to keep some kind of cross platform code base and Cygwin offers non-cross-platform-standardized libraries/api:s (i.e. posix) to be executable without having to #ifdef the code base to be buildable and executable on Windows but MinGW doesn't supply those posix libraries on Windows (maybe a few), so using GCC/MinGW is not an option and I guess we'd go with MSVC if we wanted to port our code completely std::filesystem is supposed to be cross-platform (and easier to use than various posix-library-C-functions) though and it is cross-platform per definition but, then again, not when using Cygwin > I hope we're not still talking at cross purposes, though that it certainly > possible! > > Best wishes - EM > -- > 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