From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id A59573854834 for ; Thu, 19 Nov 2020 10:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A59573854834 Received: by mail-lf1-x130.google.com with SMTP id s30so7391888lfc.4 for ; Thu, 19 Nov 2020 02:03:26 -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:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=LOlJzF8AgjdB6S5GT6zTRKq7DgxfPyo23F8iQBNeWAw=; b=qH5TIQ9D2bf4q/O1nYSDJRPAFMzTAM8X6T3ACsUop4d7NiY+aQG0c2oiFgA3K2DhJW cT9a/X9vbSwhKj+zAreNuL0Wg+wBvewtXhNsIBYp+oKwOTp1Z7wENLvFY9mKlrWCpsNC f7/oM+FU76q5myJx+lO783Mh/FZbAc3ZiAQnTjDW25UQ9L2zvrQapPNDMZEIq7WjOalK jImeYpQSLyHyvAGniBuvisQNn5UWed9vGcQ196z1ATOiamhlUGScToovBa+lV9kEETEo nWAvRnWJrtbdw2Olw3RoGIEk1usGsRAAJ9XBqzhU+HpCM0kiEm773VUEbjBvNUk+evIu S9aA== X-Gm-Message-State: AOAM530I4gD0VJZbgpCp5qGNfJfXzGBODFfjMez5b7pyGGE1p8rGhnd/ dKZnTboMIjRCSJXoe3X2hBGgPF/taYo= X-Google-Smtp-Source: ABdhPJxzzdO3WM+uuzwa4PH40OJn15TwOSoMvpYuR/4SR3nRBm9cpzwGutmSOPeIQgGmyd9xcrofeg== X-Received: by 2002:a19:344:: with SMTP id 65mr5240402lfd.363.1605780205193; Thu, 19 Nov 2020 02:03:25 -0800 (PST) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id w15sm3956271lfn.297.2020.11.19.02.03.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 02:03:24 -0800 (PST) From: To: Cc: =?utf-8?Q?'Ren=C3=A9_Berber'?= References: In-Reply-To: Subject: Sv: g++ and c++17 filesystem Date: Thu, 19 Nov 2020 11:03:23 +0100 Message-ID: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVqVR8ItA= Content-Language: en-gb X-Spam-Status: No, score=-3.0 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: Thu, 19 Nov 2020 10:03:29 -0000 > > 18 nov. 2020 kl. 17:26 skrev Ren=C3=A9 Berber via Cygwin = : > > > > =EF=BB=BFOn 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: > > > >>>> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: > >>> > >>>> The filesystem-library as a part of C++17 seems to have some > >>>> defects and flaws in the cygwin-package and pretty much every > >>>> lexical- and canonical operation works in mysterious ways (or not > >>>> at all) > >>> [snip] > >>> > >>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 [snip]=20 =20 > As stated earlier, it seems like using mingw g++/libstdc++ (from the > cygwin-package-manager) it seems like it works better, but then you = can=E2=80=99t > mix with other posix/cygwin mechanism (that uses cygstdc++) without > breaking ODR (and probably some memory models etc as well) so maybe > someone do have some insightful info about this ? How = =E2=80=9Cspecial=E2=80=9D is > cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in = that > library (cygstdc++) ? I think the problem can be viewed in = /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/bits/fs_path.h and ... #if defined(_WIN32) && !defined(__CYGWIN__) # define _GLIBCXX_FILESYSTEM_IS_WINDOWS 1 # include #endif ... that when build in CYGWIN will make the stdc++ think it is not on = Windows (and I guess cygstdc++-6.dll will be built without = _GLIBCXX_FILESYSTEM_IS_WINDOWS implicitly), thus, the = std::filesystem-library will act as it is on a Posix-system, but it is = not and thus it makes wrong assumptions It seems like the (ordinary) MinGW-shipping includes these directives = (!defined(__CYGWIN__)) as well and my naive take on this is that it is a = (the) mistake The underlaying filesystem IS Windows and NOT Posix, but my guess is = that (some) Posix-system-calls and/or assuming Posix-style-paths are = invoked when _GLIBCXX_FILESYSTEM_IS_WINDOWS is not set I guess the correct way would be to let _GLIBCXX_FILESYSTEM_IS_WINDOWS = and maybe just have a #ifdef (__CYGWIN__) as an extra option ONLY when = handling lexical stuff, i.e. it allows both Windows- and Posix-styles = but the system calls should always be Windows calls (and I guess this = would imply better performance as well to not need to walk through the = whole Cygwin-posix-abstraction) I might be totally wrong, so does anyone have any take on this ? Best regards, Kristian=20 > Best regards, > Kristian [snip]