enhanced renameat2 to support raw syscalls#2657
Conversation
- replace libc::renameat2() with libc::syscall() for broader compatibility - define syscall numbers manually for multiple architectures - update conditional compilation to support all Linux environments - expand test coverage for additional architectures added changelog entry for renameat2 support rust fmt handle all linux archs instead of explictly defining them
hz2
force-pushed
the
enhance-renameat2-portability
branch
from
be76b59 to
c841902
Compare
asomers
left a comment
asomers
left a comment
There was a problem hiding this comment.
Nix avoids raw syscalls for good reason. Why do you need to do this? If musl does not define renameat2, then renameat2 shouldn't be used in musl.
Do you mind sharing the good reason? I am personally unfamiliar with why it is or is not a good idea, but would love to learn.
The discussion here outlined the desire to use the nix crate, but I can continue with using raw syscalls. |
|
It's mainly about type safety. Using raw syscalls provides absolutely none. Using the libc bindings is much safer. Furthermore, there is often important logic in the platform's libc . For example, Go's insistence on using raw syscalls is the reason why many Go programs are still forced to use fork/exec rather than the higher performance posix_spawn. |
|
Thanks for the explanation, makes sense. Closing the issue. |
2 participants
What does this PR do
libc::renameat2()withlibc::syscall()for broader compatibilitycontext: uutils/coreutils#8391
Checklist:
CONTRIBUTING.md