From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6D4943857424 for ; Tue, 28 Jun 2022 08:36:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D4943857424 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-84-bGkX55b2P22LL9MpVh5MDA-1; Tue, 28 Jun 2022 04:36:27 -0400 X-MC-Unique: bGkX55b2P22LL9MpVh5MDA-1 Received: by mail-qk1-f199.google.com with SMTP id w16-20020a376210000000b006af059b17b7so11808488qkb.12 for ; Tue, 28 Jun 2022 01:36:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T7p0TIfC906CuXPaLmGO59+nAjv2kqteWPn4TKQsvwA=; b=JaGJFeXC6b6fANTrV8BesHOH26GPUY6g0y3+Q59DDIgXST3n0zkG2If1Pwq647NRdJ hOkA1ByXS1WjR0QqvTQyD4nFYXnQk28tlZnalrwM4dKxoLCR39YGc/bcIaPXO9l/zLbg HQMqXYXtbgqq5jz+3SvMYxsVK/wvd7uYzSaJcrmhQYLK032FDJeBlIrLn+bIo8z5DH/w fxYNZK+8t1chy7jgsqop8mZGElAUrFI5EqBm9J2W7XWSCYEDiXhwHgKUcW2ppWucA2px 2PAMKIDq0oTwCNPuB+z7+hDX2E6qCp8E01nuMwDpfGQ72pjY2DVZfP8SDkZ5LutIOty1 Ym9g== X-Gm-Message-State: AJIora9ehy4o0WQBZKUed56/LcmJ6XC5ryoOcd5zyzy6wuy7mtfynDYY dFtwrEZyGHXBn7iKgf7GrCzo/TV5p2RCHRaD7FPPgkuUhXwlK80pVEVzazN92LksXDQXK3muoyF V4yezkgxqbs3zVwcBeh4t3LMGDciY2Jw= X-Received: by 2002:a05:622a:118a:b0:315:b54c:a9b7 with SMTP id m10-20020a05622a118a00b00315b54ca9b7mr11942631qtk.647.1656405386512; Tue, 28 Jun 2022 01:36:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vFxD9oXJ5wLKOBQZx8R0DGKx67OEAIiwCPUWw3irA10pxaa+cBNE5XzMCfdVD6Wxiop9110cHMwvCDCutwYjk= X-Received: by 2002:a05:622a:118a:b0:315:b54c:a9b7 with SMTP id m10-20020a05622a118a00b00315b54ca9b7mr11942625qtk.647.1656405386251; Tue, 28 Jun 2022 01:36:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Tue, 28 Jun 2022 09:36:15 +0100 Message-ID: Subject: Re: [PATCH] libstdc++-v3: check for openat To: Alexandre Oliva Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2022 08:36:30 -0000 On Mon, 27 Jun 2022 at 23:04, Alexandre Oliva via Libstdc++ wrote: > > On Jun 27, 2022, Jonathan Wakely wrote: > > > -#if _GLIBCXX_HAVE_DIRFD > > +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT I'll push this today. > Thanks, I had this bit in the WIP _At_path patch, as well as my updated > remove_all patch, in the latest round of tests. > > I confirm that I don't get any errors with it on an x86_64-linux-gnu > native built with openat and unlinkat forced disabled in libstdc++, but > on aarch64-rtems6, there are some fails that are not making much sense > to me. I haven't looked into any but 27_io/.../copy.cc, so I can't tell > whether they've regressed, but copy.cc's test01 did when I put this (or > variants thereof) in. > > Tomorrow I'll look into building libstdc++ with -Og or something else > with less optimization than the default, to help me make sense of what's You can just use --enable-libstdcxx-debug and then link to the libs in $libdir/debug instead of $libdir (e.g. with LD_LIBRARY_PATH). > going on that causes copy() to return without as much as creating the > destination. Again, that test is *supposed* to return without creating the destination. It's testing the failure case. > > > FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc > FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc > > .../27_io/filesystem/operations/copy.cc:5[67]: void test01(): Assertion '!exists(to)' failed. I don't know what 5[67] means, so I don't know if that's the first or second !exists(to) assertion, but this is not failing because copy returned without creating something. copy is not supposed to create anything here, and it didn't, because the previous assertion (ec == std::make_error_code(std::errc::is_a_directory)) didn't fail. So the copy function behaves correctly, but the 'to' file exists anyway. Which suggests to me another problem with mkstemp / nonexistent_path. Before rebuilding the library I'd just add an extra assertion into the test. --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc @@ -49,6 +49,7 @@ test01() VERIFY( ec ); auto to = __gnu_test::nonexistent_path(); + VERIFY( !exists(to) ); ec.clear(); auto opts = fs::copy_options::create_symlinks; fs::copy("/", to, opts, ec); I suspect this is going to fail, because 'to' already exists before you ever call copy("/", to, opts, ec). And that would happen is nonexistent_path is still broken. Do you have the commit r13-1289-g30a8f67295f412 in your tree? > FAILED: default@libstdc++,27_io,filesystem,operations,copy_file_cc > FAILED: default@libstdc++,experimental,filesystem,operations,copy_file_cc > > terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error' > what(): filesystem error: cannot copy file: File exists [filesystem-test.000001-copy_file] [filesystem-test.000001-copy_file] Again, this looks like a problem with nonexistent_path, the 'from' and 'to' paths are the same: auto from = __gnu_test::nonexistent_path(); auto to = __gnu_test::nonexistent_path(); > FAILED: default@libstdc++,27_io,filesystem,operations,equivalent_cc > FAILED: default@libstdc++,experimental,filesystem,operations,equivalent_cc > > .../27_io/filesystem/operations/equivalent.cc:4[45]: void test01(): Assertion '!result' failed. This would also happen if nonexistent_path still returns the same value twice. > > FAILED: default@libstdc++,27_io,filesystem,operations,relative_cc > > .../27_io/filesystem/operations/relative.cc:32: void test01(): Assertion 'r == ".."/p' failed. Ditto. > > Also still present: > > .../20_util/from_chars/4.cc:304: error: 'log2' is not a member of 'std'; did you mean 'log'? > > (IIRC we used to have two of these, we're now down to one) That should be fixed at r13-1315-g30aea28bd30027 now.