X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org D8C0639450FE
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1605732393;
	bh=mpZMQEzM0xnuz2St9HBm51EeBT4EmBjdU7qSbe45HYk=;
	h=Subject:Date:References:In-Reply-To:To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=TxHMTtjLME1/VpTHfj4AJk6kHTJKkunfMX6I16Ag63dm/El1tpUebXp84YVITPKBN
	V1/y6s2vDSN+d4VO+5c/M+0DLu5u8U+Xaa1/v5mtkloCDZY33jftcDV2HwnOsBE3SG
	3DhOmA8/ThVwiwi1EjNJhl8iB6ArgGRWmWuyNR1c=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org C17EF394504F
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)
Mime-Version:	1.0 (1.0)
Subject:	Re: g++ and c++17 filesystem
Date:	Wed, 18 Nov 2020 21:46:25 +0100
Message-Id:	<D3704C33-A283-40F0-990D-CB9806F0B09D@gmail.com>
References:	<c2d6280c-26e3-f9e7-89bd-693385a768b2 AT gmail DOT com>
In-Reply-To:	<c2d6280c-26e3-f9e7-89bd-693385a768b2@gmail.com>
To:	cygwin AT cygwin DOT 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 AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Kristian Ivarsson <sten DOT kristian DOT ivarsson AT gmail DOT com>
Cc:	=?utf-8?Q?Ren=C3=A9_Berber?= <rene DOT berber AT gmail DOT com>
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 0AIKl1ta026005

> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin <cygwin AT cygwin DOT com>:
> 
> On 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
>> So by this you're saying that cygwin-applications cannot handle the
>> filesystem it is supposed to handle ?
> 
> I'm not saying anything, I'm pointing to the relevant documentation.
> 
>> How come std::filesystem first say "It's a valid file" followed by "It's not
>> a valid file" ? Is that part of the "circumvention" ?
> 
> The documentation states that using Windows notation is not supported and may result in unexpected results (i.e. sometimes work, sometimes doesn't).
[snip]
> Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.  End of story.
Well, the sole reason behind this question was to either find an existing solution to this issue or perhaps invoke some work to improveme CYGWIN, because no developer, operator or user likes undefined behaviour and I think that we all can agree to that it would be kind of nifty if this worked as expected and thus I don’t consider this to be the end of the story

I’m thankful that you pointed out the documentation (that I already have read some while ago) and by “you” I didn’t mean you in person but more directed to the “community”

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 educate operators/users to enter paths with /cygdrive/...

... or you have to add code to kind of transform possible Windows-paths to Posix-paths (perhaps back and forth), well then you’re adding non-posix-logic (non-cross-platform-logic) to your application and that makes it one reason less to use CYGWIN 

Is there any other use cases for CYGWIN than to build applications running in Windows ? Do people use CYGWIN (shell) to operate or monitor their applications ? For all other use cases than the development (the shell) I cannot see why CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ?

So, a library can always go from undefined to defined without breaking changes, so does anyone know what the effort could be to fix this, i.e. make it work 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’t 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 “special” is cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in that library (cygstdc++) ?

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
--
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

- Raw text -