Suppress clippy::not_unsafe_ptr_arg_deref in mqueue, ptrace #1638
Conversation
| @@ -176,6 +177,7 @@ pub fn read(pid: Pid, addr: AddressType) -> Result<c_int> { | |||
| } | |||
|
|
|||
| /// Writes a word into the processes memory at the given address | |||
| #[allow(clippy::not_unsafe_ptr_arg_deref)] | |||
| pub fn write(pid: Pid, addr: AddressType, data: c_int) -> Result<()> { | |||
There was a problem hiding this comment.
ptrace::write is unsafe on Linux. Rather than suppress this warning, do we want to just make the ptrace API consistently unsafe?
There was a problem hiding this comment.
I think technically this doesn't violate Rust's safety rules. libc::ptrace doesn't dereference those addresses. Instead, it passes them to the kernel as-is. So from a safety perspective, this is similar to a Rust function that accepts a raw pointer argument but does nothing more than print its debugging form.
OTOH, you could make the argument that since any foreign function call is unsafe, and we don't really know what ptrace does, that the entire ptrace API ought to be unsafe.
I usually hew to the narrow technical definition of unsafe, but in this case I think making the entire API unsafe would be sensible. It would probably match users' expectations.
| @@ -115,6 +115,7 @@ pub fn mq_unlink(name: &CString) -> Result<()> { | |||
| /// Close a message queue | |||
| /// | |||
| /// See also [`mq_close(2)`](https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_close.html) | |||
| #[allow(clippy::not_unsafe_ptr_arg_deref)] // mqd_t is a pointer on some platforms | |||
There was a problem hiding this comment.
Unfortunately, Clippy is right about this. Since mqd_t is a typedef, the user is allowed to do pretty much anything with it. As an example, this code will segfault:
#[test]
fn invalid_mqd_t() {
let mqd: libc::mqd_t = std::ptr::null_mut();
mq_close(mqd).unwrap();
}I think Nix should fix this by defining a Newtype around mqd_t.
| @@ -176,6 +177,7 @@ pub fn read(pid: Pid, addr: AddressType) -> Result<c_int> { | |||
| } | |||
|
|
|||
| /// Writes a word into the processes memory at the given address | |||
| #[allow(clippy::not_unsafe_ptr_arg_deref)] | |||
| pub fn write(pid: Pid, addr: AddressType, data: c_int) -> Result<()> { | |||
There was a problem hiding this comment.
I think technically this doesn't violate Rust's safety rules. libc::ptrace doesn't dereference those addresses. Instead, it passes them to the kernel as-is. So from a safety perspective, this is similar to a Rust function that accepts a raw pointer argument but does nothing more than print its debugging form.
OTOH, you could make the argument that since any foreign function call is unsafe, and we don't really know what ptrace does, that the entire ptrace API ought to be unsafe.
I usually hew to the narrow technical definition of unsafe, but in this case I think making the entire API unsafe would be sensible. It would probably match users' expectations.
Fix the BSD builds on nightly.