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.129.124]) by sourceware.org (Postfix) with ESMTPS id 8E66F38582B4 for ; Mon, 27 Jun 2022 15:57:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E66F38582B4 Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-605-4X00WFn-POOmcBnnXEPpfg-1; Mon, 27 Jun 2022 11:56:59 -0400 X-MC-Unique: 4X00WFn-POOmcBnnXEPpfg-1 Received: by mail-ed1-f69.google.com with SMTP id n8-20020a05640205c800b00434fb0c150cso7389350edx.19 for ; Mon, 27 Jun 2022 08:56:59 -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=L+K6L1Bt74+l8m3K5j7V2O1jLcydzhcSi29gN4IfxNQ=; b=qXoXHc45z1BCNpiUB6p4c+ePILm+8FUqr29/uHWRuSRG3TX8jS80AQzg/VlDzfmu6e paU1AyZoMvpFDfxFlkeQXJ6GQO1zBXx9fHn/VKuQRMutF/+Jiah4DzhPMa3VXNilRxQn hRB3TACAA9UdKsu2/3q/f4KhrfCkrUMyvf/fGX41jxnYfqyrTsHpRpD90vFKLHD178vn DYyQm62XDzu7v3+NzV6K0oxJqqnUbEXNohuZg+FyyrLKoVWUQR13l6J0j8Xn+Eq2Q1tt BLkNKMDUcQ2PGdhLk9v2+u7Ap0BH68MJ/zrw/HeF2JWd1GNm0Sgqbf5cfv5EUCZzCR5C 2XEQ== X-Gm-Message-State: AJIora+hjTzS5EvLT91WzmibaHIjB0cYUos8ivNKAufxB19Ek7WDXUqi Ld1ArD8cYfsBUuhqm9wzUyakLo2JT+s7iogCN5gHNQN5iWsOVgwPYwch1fLcGanPH9GM9QMELgl ap5wHwjWz/9yxiJfTGYpI0kR+AC2CK2s= X-Received: by 2002:a05:6402:3298:b0:435:8145:e6db with SMTP id f24-20020a056402329800b004358145e6dbmr17397082eda.294.1656345418141; Mon, 27 Jun 2022 08:56:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v9grt4SEPSguuWv/wCFxuet46fMhxfxuEK4YTEzzEthwOvrT23D6p2VZJiLHOU03f2Wx+qk7vdGHYgbyCR10Q= X-Received: by 2002:a05:6402:3298:b0:435:8145:e6db with SMTP id f24-20020a056402329800b004358145e6dbmr17397058eda.294.1656345417921; Mon, 27 Jun 2022 08:56:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 27 Jun 2022 16:56:46 +0100 Message-ID: Subject: Re: [PATCH] libstdc++-v3: check for openat To: Alexandre Oliva Cc: gcc Patches , "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: Mon, 27 Jun 2022 15:57:01 -0000 On Mon, 27 Jun 2022 at 15:00, Jonathan Wakely wrote: > > On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely wrote: > > > > On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote: > > > > > > On Jun 27, 2022, Alexandre Oliva wrote: > > > > > > > It looks like the atp.pathname is missing the nonexistent_path > > > > assigned to variable dir in test_pr99290, so we attempt to open > > > > subdirs thereof as if with openat. > > > > > > This appears to be caused by the early return in fs::_Dir's ctor: > > > > > > _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow, > > > [[maybe_unused]] bool filename_only, error_code& ec) > > > : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec) > > > { > > > #if _GLIBCXX_HAVE_DIRFD // && 0 > > > if (filename_only) > > > return; // Do not store path p when we aren't going to use it. > > > #endif > > > > Yes, this needs a fix. If we don't have openat then we always need a > > full path relative to the CWD, not just a filename relative to a file > > descriptor for the parent directory. > > > > I think we need to store the directory's path if any of dirfd, openat > > or unlinkat is missing. i.e. --- a/libstdc++-v3/src/c++17/fs_dir.cc +++ b/libstdc++-v3/src/c++17/fs_dir.cc @@ -48,7 +48,7 @@ struct fs::_Dir : _Dir_base [[maybe_unused]] bool filename_only, error_code& ec) : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec) { -#if _GLIBCXX_HAVE_DIRFD +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT if (filename_only) return; // Do not store path p when we aren't going to use it. #endif > > > > > > > > > > if (!ec) > > > path = p; > > > } > > > > > > but somehow disabling the early return to force the saving of path > > > appears to break copy(): copy.cc's test01() succeeded without the '&& 0' > > > that I've commented-out above, but started failing to create 'to' in the > > > copy at line copy.cc:54 when I put it in to prevent the early return. N.B. it's not supposed to create 'to' there, that line is checking that it fails and reports an error. Could the FAIL simply be that rtems gives a different error, not EISDIR as the test expects? VERIFY( ec == std::make_error_code(std::errc::is_a_directory) ); Although that shouldn't depend on anything target-specific, because the libstdc++ code itself reports that error: else if (is_directory(f) && create_symlinks) ec = std::make_error_code(errc::is_a_directory);