From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely@redhat.com>
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 6359C38418BE
 for <gcc-patches@gcc.gnu.org>; Mon, 27 Jun 2022 13:32:48 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6359C38418BE
Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com
 [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-577-xBgPIC8YPdSyMQ4h0mOuYg-1; Mon, 27 Jun 2022 09:32:46 -0400
X-MC-Unique: xBgPIC8YPdSyMQ4h0mOuYg-1
Received: by mail-ej1-f69.google.com with SMTP id
 qa41-20020a17090786a900b00722f313a60eso2404369ejc.13
 for <gcc-patches@gcc.gnu.org>; Mon, 27 Jun 2022 06:32:46 -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=Iqe31cFMQdPYmqHIzUQ4+psilfBmhBENilRV5lJ4Cho=;
 b=mZtRdhcfRUYdFMWz3FTF4O1MngDh1Ag65h+vF0rV8ZpGWRSVcmj6aB1ME1R4GnG4iq
 TFGbvP57sEUV/FNmL3NYTeunfY5RKX+LrDJlD13GEYpAYz1boyKdQC7BWoNAV+v1J7Bq
 rM22vCFv9C9RHEo4uVPT1EPGVbwa2qOS8cl/LPmA23WxUbiVaZ9L5UwsuHDeANKY6jrd
 IMKWvVqkclLVjNAqDvzxbJbxdwNNRN8/P03VzdRl8Z9wL9B1E9PFihkkgY6yo9qqQexi
 ft16Mo0DiFjNa2lSHLjnMOzU3klvaUac99+Rt9FZhb+o1QjmUpbMVVLohS35DLy6bacO
 zXKg==
X-Gm-Message-State: AJIora8uQ+D56QDVKTOBjVqqSm/OYHKBYEF6e9bpdPPv2zphK39ORFga
 NYNfebzsFn+bnZDOH5Y3GRvfq49UDeD59CUwzhEKlr72BFI0Fb7XUYFD6Z4bIl/G2UQEWYvCbG7
 /9oElis3H9itl5tjqYoanRw6zkGnjp4AHmA==
X-Received: by 2002:aa7:de88:0:b0:435:9a54:168a with SMTP id
 j8-20020aa7de88000000b004359a54168amr16410719edv.73.1656336765747; 
 Mon, 27 Jun 2022 06:32:45 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1sdEZbHolOpE8v5PxPhVMdb4Yi9ghxNdGyBTV8BhqC70aRfjWNDXsvkqDmPCPRJ7fHxq8JuF7jhoCypeTWlpiE=
X-Received: by 2002:aa7:de88:0:b0:435:9a54:168a with SMTP id
 j8-20020aa7de88000000b004359a54168amr16410652edv.73.1656336765603; Mon, 27
 Jun 2022 06:32:45 -0700 (PDT)
MIME-Version: 1.0
References: <or1qvh9p3u.fsf@lxoliva.fsfla.org>
 <CACb0b4=1zk4Ls1Y0b9yEb0TxScnx_odzonU3-ovE=UdeAdR-5w@mail.gmail.com>
 <orwnd74oym.fsf@lxoliva.fsfla.org>
 <CACb0b4=CE=WZuDSr4E1g=oDU7e4WgK6ENUG4M5QUrAbYhdUnjQ@mail.gmail.com>
 <or4k0b326o.fsf@lxoliva.fsfla.org>
 <CACb0b4mSarKMponQpYS8zpk1HwW9h-+rdunCzcPDscHFYzF3ug@mail.gmail.com>
 <ory1xixqmw.fsf@lxoliva.fsfla.org> <ortu86xnnl.fsf@lxoliva.fsfla.org>
In-Reply-To: <ortu86xnnl.fsf@lxoliva.fsfla.org>
From: Jonathan Wakely <jwakely@redhat.com>
Date: Mon, 27 Jun 2022 14:32:34 +0100
Message-ID: <CACb0b4m3rucYga74v2n9AQ5aa9WxJ+GuXhp=VPPKtWdmShGQdQ@mail.gmail.com>
Subject: Re: [PATCH] libstdc++-v3: check for openat
To: Alexandre Oliva <oliva@adacore.com>
Cc: gcc Patches <gcc-patches@gcc.gnu.org>, "libstdc++" <libstdc++@gcc.gnu.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-4.6 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=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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2022 13:32:51 -0000

On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Jun 27, 2022, Alexandre Oliva <oliva@adacore.com> 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.


>
>     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.
>
> Does that make any sense to you?

No, I'll have to debug the test. I thought that not storing the path
was just an optimization (to avoid parsing, decomposing, and
allocating a path object that we will never use).