clippy::not_unsafe_ptr_arg_deref: this public function might dereference a raw pointer but is not marked `unsafe`

error: this public function might dereference a raw pointer but is not marked `unsafe`
 --> main.rs:2:30
  |
2 |     println!("{}", unsafe { *x });
  |                              ^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#not_unsafe_ptr_arg_deref
  = note: `#[deny(clippy::not_unsafe_ptr_arg_deref)]` on by default

pub fn foo(x: *const u8) {
    println!("{}", unsafe { *x });
}

// this call "looks" safe but will segfault or worse!
// foo(invalid_ptr);

pub unsafe fn foo(x: *const u8) {
    println!("{}", unsafe { *x });
}

// this would cause a compiler error for calling without `unsafe`
// foo(invalid_ptr);

// sound call if the caller knows the pointer is valid
unsafe { foo(valid_ptr); }

#[allow(clippy::not_unsafe_ptr_arg_deref)]
fn my_function() { /* ... */ }

[lints.clippy]
not_unsafe_ptr_arg_deref = "allow"

cargo clippy -- -A clippy::not-unsafe-ptr-arg-deref

Clippy's own documentation

What it does

Checks for public functions that dereference raw pointer arguments but are not marked unsafe.

Why is this bad?

The function should almost definitely be marked unsafe, since for an arbitrary raw pointer, there is no way of telling for sure if it is valid.

In general, this lint should never be disabled unless it is definitely a false positive (please submit an issue if so) since it breaks Rust’s soundness guarantees, directly exposing API users to potentially dangerous program behavior. This is also true for internal APIs, as it is easy to leak unsoundness.

Context

In Rust, an unsafe {...} block is used to indicate that the code in that section has been verified in some way that the compiler can not. For a function that accepts a raw pointer then accesses the pointer’s data, this is generally impossible as the incoming pointer could point anywhere, valid or not. So, the signature should be marked unsafe fn: this indicates that the function’s caller must provide some verification that the arguments it sends are valid (and then call the function within an unsafe block).

Known problems

• It does not check functions recursively so if the pointer is passed to a private non-unsafe function which does the dereferencing, the lint won’t trigger (false negative).
• It only checks for arguments whose type are raw pointers, not raw pointers got from an argument in some other way (fn foo(bar: &[*const u8]) or some_argument.get_raw_ptr()) (false negative).

Example

pub fn foo(x: *const u8) {
    println!("{}", unsafe { *x });
}

// this call "looks" safe but will segfault or worse!
// foo(invalid_ptr);

Use instead:

pub unsafe fn foo(x: *const u8) {
    println!("{}", unsafe { *x });
}

// this would cause a compiler error for calling without `unsafe`
// foo(invalid_ptr);

// sound call if the caller knows the pointer is valid
unsafe { foo(valid_ptr); }

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Related lints

• never_loopthis loop never actually loops
• non_octal_unix_permissionsChecks for non-octal values used to set Unix file permissions
• nonsensical_open_optionsChecks for duplicate open options as well as combinations that make no sense
• option_env_unwrapthis will panic at run-time if the environment variable doesn't exist at compile-time
• out_of_bounds_indexingindex is out of bounds
• panicking_overflow_checksDetects C-style underflow/overflow checks

All 847 Clippy lints · Rust compiler errors · Cargo.toml checker