Clippy lints / Correctness
Clippy lint · Correctness · checked with Clippy 0.1.99
clippy::transmuting_null: transmuting a known null pointer into a reference
What it meansChecks for transmute calls which would receive a null pointer. It is in the correctness group and denied by default (the build fails).
What you see
error: transmuting a known null pointer into a reference --> main.rs:3:31 | 3 | let null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#transmuting_null = note: `#[deny(clippy::transmuting_null)]` on by default
Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.
Does it matter?
Transmuting a null pointer is undefined behavior.
Code that is almost certainly wrong. Denied by default: the build fails until you fix it or allow it.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
let null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::transmuting_null)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
transmuting_null = "allow"One run
cargo clippy -- -A clippy::transmuting-nullThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Clippy's own documentation
What it does
Checks for transmute calls which would receive a null pointer.
Why is this bad?
Transmuting a null pointer is undefined behavior.
Known problems
Not all cases can be detected at the moment of this writing.
For example, variables which hold a null pointer and are then fed to a transmute
call, aren’t detectable yet.
Example
let null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- size_of_in_element_countDetects expressions where size_of::<T> or size_of_val::<T> is used as a count of elements of type T
- suspicious_splitnChecks for calls to [splitn] (https://doc.rust-lang.org/std/primitive.str.html#method.splitn) and related functions with either zero or one splits
- transmute_null_to_fntransmuting a known null pointer into a function pointer
- uninit_assumed_initthis call for this type may be undefined behavior
- uninit_vecChecks for set_len() call that creates Vec with uninitialized elements. This is commonly caused by calling set_len() right after allocating or reserving a buffer with new(), default(), with_capacity(), or reserve()
- unit_cmpChecks for comparisons to unit
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::size_of_in_element_countDetects expressions where size_of::<T> or size_of_val::<T> is used as a count of elements of type TRead it next →Did this answer your question?