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 1D7F03857B95 for ; Mon, 27 Jun 2022 15:57:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D7F03857B95 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-90--W7IHBz9MCWO8eaXh2quaQ-1; Mon, 27 Jun 2022 11:56:59 -0400 X-MC-Unique: -W7IHBz9MCWO8eaXh2quaQ-1 Received: by mail-ed1-f71.google.com with SMTP id i9-20020a05640242c900b004373cd1c4d5so6657022edc.2 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=fYtgv3peC3Tu182iTxsSzlAZUgR6wK1Q+gm3IfU2YDVKJVNEEC24YSnuVq+pPXdFz7 0dFArs91ZzkO7KFR1YEKViuCT5lGOkpUTkYAvFh9i0DvNQVAososk6KOAlHzw76JEX0d xB1KpELMNWO8EM6V+tuZtR+sEFucThbw1peCwy3/dswxBOEcjtuhcvCoxrScJUs8p6e5 lFbvmtTX5FRm4pNKWoY7bg2o/UEQ2m8Xusd6gVitR+bINsmumT9P8haCURg/Od7SpM5F 6HARIFL8x6n4fvBEkq0bWcLSnZ2LrNurqpM+MDzKODvCd8oHy0UhU4CCmkG+gqSZjdKU /icw== X-Gm-Message-State: AJIora85zfGeFEDSwfJCLcc6pCAH4EJawhBIDdDUXap4FMElvpucKdZY abcH0UcxPIYl7RPClUoyOm7YVxiqf+9+kmn8Y2Gv/f2d5b1KLl9xVSZi9jwEw36tP/7lmY4gw3v JffjAVuTTRXSQY2/tHfmOA1OWkRa9CJ5bcQ== X-Received: by 2002:a05:6402:3298:b0:435:8145:e6db with SMTP id f24-20020a056402329800b004358145e6dbmr17397089eda.294.1656345418226; 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=-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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 15:57:03 -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);