From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id DD474389683F for ; Tue, 24 Nov 2020 09:32:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD474389683F Received: by mail-lf1-x136.google.com with SMTP id v14so5753708lfo.3 for ; Tue, 24 Nov 2020 01:32:24 -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=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) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id n8sm1680912lfq.2.2020.11.24.01.32.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 01:32:22 -0800 (PST) From: To: "'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> 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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@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: Tue, 24 Nov 2020 09:32:26 -0000 > On 11/23/20 8:35 AM, sten.kristian.ivarsson@gmail.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 ..." > > > > >=20 > 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 =C2=A4#=C2=A4#=C2=A4#=C2=A4 > >>>> 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 ? > > >=20 > 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) > > > > >=20 > 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=20 > >> > >> 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 ? > > >=20 > 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. >=20 > > 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 ? > > > > >=20 > 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?=20 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