[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230221040905.GE1903@voyager>
Date: Tue, 21 Feb 2023 05:09:05 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
