From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id C17EF394504F for ; Wed, 18 Nov 2020 20:46:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C17EF394504F Received: by mail-lj1-x233.google.com with SMTP id y16so3884664ljk.1 for ; Wed, 18 Nov 2020 12:46:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=6YNT1NLe+uqQqFtZ7RC2HixRiPeQbbSGWAEgjWxvIZs=; b=s+qDPbET5xc15ajEtR1W4ZcDhW6TyVLkwYknhWyMaciaex88Y8tq8ZXtLxExlWiwEq GF7n9ulaLPZeggFzW+6/mmjcS2+RjoVewXVNaKXaa8JJObK1GsSVKySJUF1Z5jhLV3dS p7eQNczum3b8VKPXqtdx8RaKTp0IhYN72x1/4QmmYdkFvsVwRgdBw+8sO7N6K4Kmv/yN kqowrVSW3+cPWuKwBIVphe/RS0uWQ7wS3HNyjs0T7zRp0iiWeLA4DdDBzoPltD4fqzWG OPc3SnPEoNXkw1xwg1rHpSL51OtW8LnVisSudCbyhbXKrGyTvKO76C1fP0Fismo6/mxJ WggQ== X-Gm-Message-State: AOAM530u9Cx3fQxSsS1gU8qfTl1RfxzpTlCDv6wSJ7F+9qKOZ4b3Gv8g jAwHTQrzFJJvFvOmQuRCBr0= X-Google-Smtp-Source: ABdhPJyRLioY4Ru0iprl3y/lklGi6L4uWl3XHIsWBfmRUTbd+NQ+XDwRZl28xtTCyAUwcznl09ZLKg== X-Received: by 2002:a2e:994:: with SMTP id 142mr4600139ljj.97.1605732388538; Wed, 18 Nov 2020 12:46:28 -0800 (PST) Received: from [192.168.86.164] (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id v1sm3786566lfq.210.2020.11.18.12.46.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 12:46:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kristian Ivarsson Mime-Version: 1.0 (1.0) Subject: Re: g++ and c++17 filesystem Date: Wed, 18 Nov 2020 21:46:25 +0100 Message-Id: References: Cc: =?utf-8?Q?Ren=C3=A9_Berber?= In-Reply-To: To: cygwin@cygwin.com X-Mailer: iPhone Mail (18A8395) X-Spam-Status: No, score=-2.9 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: Wed, 18 Nov 2020 20:46:31 -0000 > 18 nov. 2020 kl. 17:26 skrev Ren=C3=A9 Berber via Cygwin : >=20 > =EF=BB=BFOn 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: >=20 >>>> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: >>>=20 >>>> 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] >>>=20 >>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 >> So by this you're saying that cygwin-applications cannot handle the >> filesystem it is supposed to handle ? >=20 > I'm not saying anything, I'm pointing to the relevant documentation. >=20 >> How come std::filesystem first say "It's a valid file" followed by "It's n= ot >> a valid file" ? Is that part of the "circumvention" ? >=20 > The documentation states that using Windows notation is not supported and m= ay result in unexpected results (i.e. sometimes work, sometimes doesn't). [snip] > Cygwin handles the file system with no problem, but using Posix-like notat= ion, not Windows-like. End of story. Well, the sole reason behind this question was to either find an existing so= lution to this issue or perhaps invoke some work to improveme CYGWIN, becaus= e no developer, operator or user likes undefined behaviour and I think that w= e all can agree to that it would be kind of nifty if this worked as expected= and thus I don=E2=80=99t consider this to be the end of the story I=E2=80=99m thankful that you pointed out the documentation (that I already h= ave read some while ago) and by =E2=80=9Cyou=E2=80=9D I didn=E2=80=99t mean y= ou in person but more directed to the =E2=80=9Ccommunity=E2=80=9D The only purpose CYGWIN have is to make/build posix-applications runnable on= Windows and applications usually have user defined input, such as paths etc= , and on Windows that input is usually Windows-native-paths unless you educa= te operators/users to enter paths with /cygdrive/... ... or you have to add code to kind of transform possible Windows-paths to P= osix-paths (perhaps back and forth), well then you=E2=80=99re adding non-pos= ix-logic (non-cross-platform-logic) to your application and that makes it on= e reason less to use CYGWIN=20 Is there any other use cases for CYGWIN than to build applications running i= n Windows ? Do people use CYGWIN (shell) to operate or monitor their applica= tions ? For all other use cases than the development (the shell) I cannot se= e why CYGWIN would favour posix-paths over native path=E2=80=99s, but maybe I= =E2=80=99m wrong ? So, a library can always go from undefined to defined without breaking chang= es, so does anyone know what the effort could be to fix this, i.e. make it w= ork transparently/agnostic ? 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 m= ix with other posix/cygwin mechanism (that uses cygstdc++) without breaking O= DR (and probably some memory models etc as well) so maybe someone do have so= me 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 (cygs= tdc++) ? Best regards, Kristian > -- > R.Berber > -- > 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