refactor: change name arg of memfd_create() to &NixPath#2431
refactor: change name arg of memfd_create() to &NixPath#2431SteveLauC merged 6 commits intonix-rust:masterfrom
Conversation
| libc::memfd_create(cstr.as_ptr(), flags.bits()) | ||
| } else { | ||
| libc::syscall(libc::SYS_memfd_create, name.as_ptr(), flags.bits()) | ||
| libc::syscall(libc::SYS_memfd_create, cstr.as_ptr(), flags.bits()) |
There was a problem hiding this comment.
Is it possible we always use the else branch? Or does it have any drawback?
From tokio-rs/tracing#1879 I'm afraid that using libc::memfd_create may fail on some old GNU toolchain.
There was a problem hiding this comment.
Right, because the glibc wrapper may only be available since a specific version, and if you are using an older glibc and this Nix wrapper, the code won't compile. But raw syscalls are inherently unsafe, Nix tries to avoid it if possible.
There was a problem hiding this comment.
Honestly, this kind of thing has always been bothering me. I just created a tracking issue #2538 for these interfaces. May I ask about the issue you encountered with this?
There was a problem hiding this comment.
the issue you encountered with this?
Not in real-world, but a blocker I don't use nix at fast/logforth#80 (memfd.rs)
There was a problem hiding this comment.
Perhaps we should wrap the raw syscall. 😪
If we want to discuss this further, let's discuss it there #2538.
2 participants
What does this PR do
nameargument ofmemfd_create()from&CStrto&NixPath.Add a test for(Update: The test was removed because the symbolmemfd_create().memfd_createis not available under our QEMU test and I cannot find a way to stop the linker from involving it)Checklist:
CONTRIBUTING.mdBreaking changes
This is not a breaking change, since
CStrhasNixPathimplemented.