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.133.124])
 by sourceware.org (Postfix) with ESMTPS id 9103B383EC7E
 for <libstdc++@gcc.gnu.org>; Mon, 27 Jun 2022 13:32:48 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9103B383EC7E
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-526-mQL0Lng4NQi31suQ4Ydv2w-1; Mon, 27 Jun 2022 09:32:46 -0400
X-MC-Unique: mQL0Lng4NQi31suQ4Ydv2w-1
Received: by mail-ed1-f69.google.com with SMTP id
 w22-20020a05640234d600b00435ba41dbaaso7184899edc.12
 for <libstdc++@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=voTuN7pkUpLchNicdVDFRmrONuRQBZ2ixhFZfp/bIkmyN0IZgfDlCFxjD9n57LM24K
 NK1+q5TWyMx1sxfNschHXZ3u/9A1t4dkHD/xN7a8KRpgl+WVR84Dx0dV+bIQJTpytvWt
 KPili0RduDqA0v9x7j3xRvIG2JKHCxVL8vYNPuch4heREJsODw01O69t6Ed1czYXBfqF
 RbzbXBH7FoljM4X10wSRiHhbtZpha2lZN/ChpJs2vRop32qBeQeD7uwvLvoghYaDbHU3
 O2ksHdlDsxO6KmxH9gqj2+2K3VIH4MbDI2eZRlUe7Nx/oi6i54voPXy8i6S55KRgV7to
 l0yQ==
X-Gm-Message-State: AJIora/Dw4suZmue5nnnChKe5qOBDD8NPegmqXT5z5aTBLBMtyeEgAJS
 idqKX98cKyZ8JQXL60jH+Aj3uBIp2kEFN0BUFIYBvkd7BLxTB2Qik+cxo0BSgwLn2Bvb82uCWMn
 VPmFPJSXq/TwxuDG6jdmG+ue0eGj71+A=
X-Received: by 2002:aa7:de88:0:b0:435:9a54:168a with SMTP id
 j8-20020aa7de88000000b004359a54168amr16410721edv.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=-7.4 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 <libstdc++.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/libstdc++/>
List-Post: <mailto:libstdc++@gcc.gnu.org>
List-Help: <mailto:libstdc++-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2022 13:32:49 -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).