From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <10walls@gmail.com> Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 730923854819 for ; Mon, 23 Nov 2020 11:09:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 730923854819 Received: by mail-pf1-x42d.google.com with SMTP id x24so2311842pfn.6 for ; Mon, 23 Nov 2020 03:09:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:cc:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JLcTgcg0amvEJRm9X9UNJ8Hg7o4Jy5cyK+FCgCMTlrw=; b=n0QlaZQ7aGCiK0VO6Yj6iVIQ9oaqLacwJy5VrWhizQVzFeDYnz0BPFzN5CIVO34HoA fmV4q/Hy73IYwYbCzwtPT/bTBigz+fc0lN8zrxq7MEaWYqT16lgI21UAK9WSXYg1RSgN qrWIlONiNyfcBE9Q9Z7/YMcgF6PA9B7kykbFSbgds2lVcg37lkd+gqcUqfGcLxlxznoj TYVW+13LWC6gCjLc66sWcFC/EuBHubLukseGlL3/h5u6orSvFucz5I7krKoIZysQ0JLW EV5FHsx1zzUS8ijyV0sQDMziPpcAXBNNi9nS0/2qxpGd8bPkZ2psuIvL+hCiQmZ07S5R 47Cg== X-Gm-Message-State: AOAM531vy43rMEuGSs+XRgpgoJTH4ehMVBPh+9/1dn5dxCm96tfHODfz ysT7ruNl1yT8iLT2Eq4n2Iw= X-Google-Smtp-Source: ABdhPJw9/mJebdUBGUPrBT0iQPi3itzD5wMqG4n8rb3ytzEdA3DK2+KJ4Sbi87vROFCfD3TOBwgwjA== X-Received: by 2002:a63:5262:: with SMTP id s34mr27180089pgl.382.1606129764633; Mon, 23 Nov 2020 03:09:24 -0800 (PST) Received: from ?IPv6:2001:f40:91b::3:d7e0? ([2001:f40:91b::3:d7e0]) by smtp.gmail.com with ESMTPSA id m8sm10316883pgg.1.2020.11.23.03.09.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 03:09:24 -0800 (PST) To: 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> From: Jonathan Yong <10walls@gmail.com> Subject: Re: Sv: Sv: Sv: g++ and c++17 filesystem Message-ID: Date: Mon, 23 Nov 2020 11:09:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <000601d6c173$aa55d540$ff017fc0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Mon, 23 Nov 2020 11:09:27 -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 ..." > > 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 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. > 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. >> >> 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?