X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5020D389683C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1606210347; bh=AaqY6D5ut0qPLpARFCdX03Pr3lzZBWWEP3WZTBEblU4=; 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=FHLJJ5dBO2VYYE4R6qcJn9+q4AK3b+3ij91RuLZOroaoA1ZrvXpCAhtRyQTwmlEAn tU9ViPYz4Oxre9jDmRK+Z/HP3xFvL9nuKNCqSQKEr95VhJwfngs4QmQohiZgAWU/K4 ZpzhPm70opFv8AbNqWb3SZiOzK8ez3/Y96EabNXI= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD474389683F 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=jlAaESS4lV2LmvrA0IQ9kLV4uAras7AYYJIrwFsDFXI=; b=JQOrH8pl0kIfjCMocay2ONx9aF0qCNzQ1JTHMgSkUufg5K0J56MA5sKx0bwGX+7ULj 4RD4CBGz1a7YKuAdNqyG2F8gR2c+i+5W3Ik9e+IjFCH357dZp3xIIlciF5Vk7yTJA2CV 7KaIlu8WJRl1xWlhGJ33JWSNLfe2+PJpLAzl8L7OYuAck0K5DwJbjTPOs04iVML3yjqN 4uIN3Bzc1YrFJ/gw9ufgpZTttmPk0ipkHmV1nAimGoDJGjUlhJy10CokNEbwYUojNkqz T6CUe/uGNBc1B5Y2P5PoF4vxhCUjeCgN7VtqXPzYmSpDIHYQXqmPXjW/NkWC9Uubttnk nfxA== X-Gm-Message-State: AOAM531anUNdaoHBgtTEB+vkGXPomDGOFy6ijyXwvDgfRzJ3DrYVco32 3Et2UTyCIbZlQFDqQLuFf04= X-Google-Smtp-Source: ABdhPJxRR5EkWZIdSXNlfdXgCP2QgTQuZeUCCAVEY2EcjG3PeK5V4PDMJk+FByDADY5HxOgraWAujw== X-Received: by 2002:ac2:5462:: with SMTP id e2mr1497281lfn.552.1606210343126; Tue, 24 Nov 2020 01:32:23 -0800 (PST) To: "'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> In-Reply-To: Subject: Sv: Sv: Sv: Sv: g++ and c++17 filesystem Date: Tue, 24 Nov 2020 10:32:22 +0100 Message-ID: <000a01d6c244$b64bbd70$22e33850$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUA3PghxQI7mYCPAhTJa9sCXpfa/AHDfHWzqPhYgdA= 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="utf-8" Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 0AO9WsxR015850 > On 11/23/20 8:35 AM, sten DOT kristian DOT ivarsson AT gmail DOT com wrote: > >> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote: > >>>> 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) > >>> > >> > >> That is not correct, \ is a valid filename under *nix, but not on > Windows. > >> I don't think the standards specify what filenames or character sets > >> are valid. Cygwin strives for *nix compatibility, anything else is > secondary. > > > > > > I should have made my point clear; "All the implementations of > std::filesystem for Windows ..." > > > > > > That is an incorrect understanding, Cygwin is NOT Windows, it is its own > platform, you should not consider it even Windows unless you are working > on Cygwin internals. I beg to differ. My claim was that all the std::filesystem implementations I've seen for Windows, except Cygwin, handles both '\' and '/' and that was my point (Cygwin handles it in some circumstances) so that point is perfectly valid I'm not considering either '/' or '\' in the code. I'm working with a path. I don't care what kind of separators the path handled to the application have. I want std::filesystem to work properly even if the folder-separator in current platform is ¤#¤#¤#¤ > >>>> 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 > >>> > >> > >> Cygwin is not Windows, it runs on Windows, but it is not Windows. You > >> should use mingw if you want Windows style paths. There isn't a > >> magical tool that allows you to have it both ways. > > > > As I'm trying to say, Cygwin already accepts Windows-style-paths in some > circumstances and thus it have SOME magic, so why not extend that and thus > make it easier to use Cygwin on its target platform, i.e. Windows ? > > > > Because libstdc++ is not part of Cygwin, it is part of the GCC project, > developed by completely different developers. GCC runs on Cygwin, so it is > expected to use standard *nix API, not windows. Windows path conversions > are entirely unreliable, see the mess that is MSYS, when Windows and *nix > paths collide. I think you have misunderstood my point completely. I know that they are unreliable and that's what I'm trying to have a discussion about, because I cannot see why it has to be unreliable and how it not could be fixed > > As I've said, to use MinGW along with Cygwin would be very tricky > > without bumping into ODR/memory issues > > > > I don't think MinGW alone give us enough support alone to keep our > > code base non platform specific (*nix+windows) > > > > > > If you are on Cygwin, use *nix APIs and paths, that's the end to it. You > should not mix Cygwin compiled code with MinGW. About the code, that's exactly as I stated > >> > >> Yes, cross platform, you can use std::filesystem on Linux, Cygwin, > >> Windows, Macs, but it certainly cannot do anything that can't be > >> handled for the underlying platform. For Cygwin, it means using *nix > >> paths, not Windows. > > > > Exactly, so why obfuscate the underlaying platform with a Posix-layer > that also can do exactly just what the underlaying platform can and then > back to some standard interface again (i.e. std::filesystem) which make a > roundtrip that only can result in loss of information/functionality ? > > > > Because Cygwin is exactly that, to emulate POSIX layer on Windows, if > POSIX mandates exposing Windows paths, then you would see Cygwin reworked > to support it. > > > I rather have a dialogue of how that that could be done rather than > "Cygwin is *nix, deal with it" or at least it would be nice to hear if > someone do have some insightful thoughts of why it must the way it is or > why it would be so hard to make parts (e.g. std::filesystem) more useful ? > > > > > > That's not what Cygwin is for, you ignore everything while conveniently > claiming to be looking for "insightful thoughts". You still haven't > answered where is it in the POSIX standard requires backslashes to be used > as separator or how are you going to make other *nix platforms accept such > a change? Did I get a question about where I think that POSIX requires backslashes or did I make such claim ? If one of them, I have missed that question and I have certainly not made any such claim All I'm saying is that I'd like std::filesystem in Cygwin to work properly and I still cannot see why that cannot happen ? What would the drawbacks be if std::filesystem worked more transparent (i.e. correct) and made Cygwin more useful ? I don't think the community would shrink ! Kristian -- 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