From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTPS id 962DA385734E; Thu, 23 Jun 2022 04:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 962DA385734E Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 46A8211619F; Thu, 23 Jun 2022 00:41: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 iX7VLzWUTx0X; Thu, 23 Jun 2022 00:41: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 91ADF1160E0; Thu, 23 Jun 2022 00:41:49 -0400 (EDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 25N4feE1753630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jun 2022 01:41: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: Thu, 23 Jun 2022 01:41:40 -0300 In-Reply-To: (Jonathan Wakely's message of "Wed, 22 Jun 2022 11:36:17 +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: Thu, 23 Jun 2022 04:41:51 -0000 On Jun 22, 2022, Jonathan Wakely wrote: > Otherwise, if rterms defines HAVE_DIRFD this function will return a > file descriptor and a filename (not a full path) but then > _Dir_base::openat doesn't use ::openat and so ignores the file > descriptor, and needs a full path. Yuck. It does. This may explain some of the fails I've observed and not looked into yet. How about introducing an internal wrapper class that can hold a ref to base path or an fd for a dir, or an iterator that could resolve to either, and that can be passed around instead of a dirfd that assumes openat, enabling uses of openat where available and falling back to paths otherwise? I don't have much of a sense of all the uses involved, but given the AFAICT impossibility of turning a dirfd into a pathname (even in non-pathological cases of removed or out-of-chroot dirfds), ISTM this wrapper class could demand base paths or CWD in the !HAVE_OPENAT case, and enable both uses otherwise, offering some additional type safety that the current abstraction doesn't. Does that make sense to you? -- 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