From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTPS id 24A763841464; Mon, 27 Jun 2022 12:00:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24A763841464 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9DC27116475; Mon, 27 Jun 2022 08:00:50 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kXX92-0nUX1U; Mon, 27 Jun 2022 08:00:50 -0400 (EDT) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 629DB11645B; Mon, 27 Jun 2022 08:00:50 -0400 (EDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 25RC0dYX889382 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 09:00:40 -0300 From: Alexandre Oliva To: Jonathan Wakely Cc: gcc Patches , "libstdc++" Subject: Re: [PATCH] libstdc++-v3: check for openat Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Mon, 27 Jun 2022 09:00:39 -0300 In-Reply-To: (Jonathan Wakely's message of "Thu, 23 Jun 2022 18:47:33 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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 12:00:53 -0000 On Jun 23, 2022, Jonathan Wakely wrote: > It defines a new _At_path type which contains a {fd, path} pair (to be > used together by openat and unlinkat) and a separate path to be used > on its own. This allows identifying a file within a directory > unambiguously, without being concerned with whether HAVE_OPENAT and > HAVE_UNLINKAT are defined. > With this change I don't think your patch to make dir_and_pathname() > check HAVE_OPENAT is needed. *nod*, I've amended your patch in my local tree to reverse them both. > This passes tests on x86_64-linux. Have you by any chance tried it while forcing libstdc++ not to use openat? I'm debugging 27_io/.../copy.cc on rtems with a fixed remove_all (there were bugs in the previous version I posted), and hitting an exception within the very first call of dir.__erase() in the remove_all at the end of test_pr99290, after an attempt to open "source" fails. 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. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about