From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21576 invoked from network); 21 Feb 2023 04:09:22 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Feb 2023 04:09:22 -0000 Received: (qmail 31970 invoked by uid 550); 21 Feb 2023 04:09:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31938 invoked from network); 21 Feb 2023 04:09:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1676952547; i=nullplan@gmx.net; bh=BedbMU0GKQA4KwQ8D3QQKgXo7avq1Gh3atBJwQJ4vY8=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=TFsvnld+vuiBFl1S9UT+Xx+7bL3EnWaJBSIQfZM6X7oSXf96tz5768p+gNOX5PmBR c4AcqEkBNnI/nzJt3Ynwu6dpkffP6gYrTlpzU8NY2NgRhZco3iKjbd4VnSRcze1dho 5nBEPrEq9HB763H0fKOYNiNWHu8DjoIL/1uhB+jc9LgGe7dXFwUJBoiaBJhqyf6Wqw Rv+LoqB6FdmBPOTF8cCXGWv1Z5l4LhYm2m10STtjPF5oaZsVtnPghlNy5Q9d4Pfxoj KmwnGz7LFCM7VK/HNzIFhlADO7NBsDCS7KlNAe2l0zDLrVtYqyob9Bk1syLXdI2Qxa LYyGCgRCIFLhw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Tue, 21 Feb 2023 05:09:05 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20230221040905.GE1903@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:C/ikKe1wsoSqQROzEIVxedggJnUGop9ZSZxqZ1mqRj1vym/2ZXl h9aVLDHi5dXQspfJ07V+dqP74IrTDFWWjh5vaALsp3IjSSSarJltg4bZhNCpYWuJ8HKj6Dz 4aOoq1H5MQZZ4wRYj33TawP0gMbG4IfZTTW9ENkDP4KYhE5MGWnmF94ABDOb83J3Ecbg73o hAN/3Y8538E2BzAndC4cQ== UI-OutboundReport: notjunk:1;M01:P0:2YjcpUv2h4s=;5vC4dzBCG5zOIY4rVn2ZPoUVY7i CNq7MKSuO1wLwdzzgPMFR24BUn2y0gZ4LnCUOH3KLimJjvG7QMUCE0xwL+eifnHmBJZZ5N3ps MlTmbnkH2628HrqEyjSVFX1X8xYzWtzRGezPNQVycNF1EKZbG25ih7TmISN71YxMkTmwMbdnN zXz9GsZiCleME/6atBO5pJbAtAsZB65DPt37znOq5G8vxN9u3f7J0fZcUB2pdYamqvSSu6/TV xJcViVGKpRWATd8WOSCoRPgdr3RtdzmOFa9HHmOGQpaADeLhFjbPM4yyML6NOWNbmPZot+jjw ZGJfkEZGIfPOBL6zFedirY2FHhBtohq3PiYB4D3Cia0f5bIgCPD1oI4FkpwRQf3wiwNAXrZq/ 6GJT75WTNSrEhb/2aOtlrA5by8iKwRz3PoE7laakfboFbXB2t3qp8XPS04a02FKJRKsAv2NTV AIDzXMtGGhpiOK3U8W7ljRBdFDXqFneWVVvzj3mhHkf9DBYh0Ma41wUD3K322N1lXmBScE2hl bjCDAdBm197dooYSffNF8L8k1IjxvpRww4JCEFu6yw/ACDMJ26+9XaKhJYZvD3Er3g77Qgv2Z CgV3M/aT88rZJXB6xp7OIU5yMK6DjCpqVTZIYTDh5d7prlN4dRWnS5SO1HhI1XS21NWpbC5iR tQlG6RiB+gvsKj/ZhDHZf43MpO+DOQwoJ6ILTEw+Lr9yLFvcfEx1ErSCzexRwJ/+HPLc9+U1W CVsa+XXylqNTkz37ZDvZgLDLUgR/XrWuJ/d5/j5OeMXlWT97u/WtOjVdmugw3Qa8sQ8cFddTi RUH7iJjeJqolSy4fxTFvoVOynPu7ZeBuqh3tZ3lFdaD1cmvaGPODhgJkjDipPwofaFI04eR7L aMVd3ZPnJqdl1+QiR3Q1qIhwORW+BOdzlV4DUYqxaQ/uVxoEbVvngzwbJd/HGgL9e+FdINa2P 6n6qVg== Subject: Re: [musl] Feature request: expose Linux-specific renameat2 function On Tue, Feb 21, 2023 at 12:28:41AM +0100, vi0oss wrote: > Does not include RENAME_EXCHANGE, RENAME_NOREPLACE or > RENAME_WHITEOUT constants that are likely to be the > reason to use renameat2 instead of renameat, but this > should still simplify linking issues arising from the > use of renameat2 and enable simpler workarounds. I'm wondering why this system call cannot be handled like every other new system interface: By making the users copy the necessary definitions into their projects and wrapping the syscall themselves while the libc does not contain them. I don't think the patch could be applied as-is. There is little obvious reason (and no reason given) why this needs to be added to the renameat.c file instead of its own file. Nor is it obvious why the abovementioned constants cannot be added under _GNU_SOURCE. If they are kernel interface, they cannot change anymore. Ciao, Markus