From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 39EE53844046 for ; Tue, 24 Nov 2020 11:35:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 39EE53844046 Received: by mail-lf1-x134.google.com with SMTP id z21so28359659lfe.12 for ; Tue, 24 Nov 2020 03:35:44 -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=LGCldSvb+V/QSVidWDAMfjJ8GPZDxD85rcVJVMiAHS8=; b=fCBs9IIkUT6sYXb/3kT8OCljl09XNtVXqunF3lDHwtkUplJ6P48t5WgK9hq6z5Husq M/CmUF69z7zfC3MBdahO2cnc/L76NsUpOrLMQq+O60rpR3dCSQwIPrhSfLoxqT/hrhB4 nE8mvpfiac1+ulFe+3tToxcKIvclrzliQuC7XVCGGRuThLCaXaJI0Z9QLnV7oN8w6cWR w4mRJvaoDaQgB/GeSlBk06goAURNOlC4mU0tajt2YVIVweXyWGredrfw/Mr4dXXi3l3h fhADWhM0g4w/vKFxQzJ0gf+CUwtKh220y3G6cWERIXGtDUtM//VwREMmy5sfLv0oVfzT +zig== X-Gm-Message-State: AOAM532qzjt6Pri2vmEf2cK4mQ/eDAZ1BXG0a+qxfkOPB1Za0AxEl9NA /E/GMxiUcV3sfx5gzq0/xO8= X-Google-Smtp-Source: ABdhPJwirbMsirL7vi6TBR00ZgQqQS3XdpP1hgOEEh7HiDleg7WxjrdRtOqKKCEmsHqVF4yWbV/BRw== X-Received: by 2002:ac2:5a46:: with SMTP id r6mr1497857lfn.293.1606217742925; Tue, 24 Nov 2020 03:35:42 -0800 (PST) Received: from JOKK (static-213-115-54-10.sme.telenor.se. [213.115.54.10]) by smtp.gmail.com with ESMTPSA id f17sm1701930lfc.158.2020.11.24.03.35.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 03:35:42 -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> <000a01d6c244$b64bbd70$22e33850$@gmail.com> In-Reply-To: Subject: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem Date: Tue, 24 Nov 2020 12:35:40 +0100 Message-ID: <001801d6c255$f0e115a0$d2a340e0$@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/AHDfHWzAafgnf4BRx5CO6jhA9fw X-Spam-Status: No, score=-2.5 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 11:35:45 -0000 [snip] > std::filesystem POSIX mode is common to all POSIX platforms where > backslashes are NOT directory separators. How do you make them accept = your > demands? How are you going to force POSIX platforms allow Windows = specific > code? I've been trying to say over and over again that our code doesn't handle = any Windows specific stuff and not anywhere have I claimed that anyone = else need to handle Windows specific stuff either (except for the = internals of Cygwin of which Windows specific logic is already present) I repeat; I don't expect any of the Cygwin-Posix-functions to accept any = Windows-style-paths (though some of them, as I repeatedly have said, = already does so) and I only expect that I can operate according to the = C++-standard on an instantiated std::filesystem::path=20 > Make it try to enter subdirectories every time std::filesystem is > called? >=20 > You refuse to understand that Cygwin is NOT Windows, it is a POSIX > platform. Using Cygwin means complying with POSIX expectations and > standards. >=20 > I don't see how this conversation can continue if you still refuse to = see > Cygwin as something separate from Windows. Besides, you have already > answered your question by ruling out MinGW, so Microsoft Visual Studio = it > is. I repeat (again); neither MinGW/MSVS is an option because we're trying = to use Posix and C++ Just to be clear: - Our code DOESN'T handle Windows-style-paths explicitly in any way - We DON'T expect Cygwin-Posix-file-related-functions to accept = Windows-style-paths - We WOULD like std::filesystem to work according to the C++ ISO = standard Does that make any sense ?=20 Kristian=20