Clippy lints / Pedantic
Clippy lint · Pedantic · checked with Clippy 0.1.99
clippy::cast_possible_wrap: casting `u32` to `i32` may wrap around the value
What it meansChecks for casts from an unsigned type to a signed type of the same size, or possibly smaller due to target-dependent integers. Performing such a cast is a no-op for the compiler (that is, nothing is changed at the bit level), and the binary representation of the value is reinterpreted. This can cause wrapping if the value is too big for the target signed type. However, the cast works as defined, so this lint is Allow by default. It is in the pedantic group and off by default.
What you see
warning: casting `u32` to `i32` may wrap around the value --> main.rs:3:9 | 3 | let _ = u32::MAX as i32; // will yield a value of `-1` | ^^^^^^^^^^^^^^^ help: if this is intentional, use `cast_signed()` instead: `u32::MAX.cast_signed()` | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#cast_possible_wrap = note: `-W clippy::cast-possible-wrap` implied by `-W clippy::pedantic`
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?
While such a cast is not bad in itself, the results can be surprising when this is not the intended behavior:
Stricter lints with some false positives. Off by default; opt in with clippy::pedantic.
How to fix it
Clippy does not fix this one automatically (its suggestion may change behaviour, so it only shows it). Change the code by hand:
Flagged
let _ = u32::MAX as i32; // will yield a value of `-1`
Write this instead
let _ = i32::try_from(u32::MAX).ok();
Turn it off, or on
It is off by default. To use it, set it to warn or deny:
Whole crate (Cargo.toml)
[lints.clippy]
cast_possible_wrap = "warn"In code
#![warn(clippy::cast_possible_wrap)]One run
cargo clippy -- -W clippy::cast-possible-wrapThe [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 casts from an unsigned type to a signed type of
the same size, or possibly smaller due to target-dependent integers.
Performing such a cast is a no-op for the compiler (that is, nothing is
changed at the bit level), and the binary representation of the value is
reinterpreted. This can cause wrapping if the value is too big
for the target signed type. However, the cast works as defined, so this lint
is Allow by default.
Why is this bad?
While such a cast is not bad in itself, the results can be surprising when this is not the intended behavior:
Example
let _ = u32::MAX as i32; // will yield a value of `-1`
Use instead:
let _ = i32::try_from(u32::MAX).ok();
If the wrapping is intended, you can use:
let _ = u32::MAX.cast_signed();
let _ = (-1i32).cast_unsigned();
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- too_many_linesChecks for functions with a large amount of lines
- missing_errors_docChecks the doc comments of publicly visible functions that return a Result type and warns if there is no # Errors section
- must_use_candidateChecks for public functions that have no #[must_use] attribute, but return something not already marked must-use, have no mutable arg and mutate no statics
- case_sensitive_file_extension_comparisonscase-sensitive file extension comparison
- cast_losslesscasts from `u8` to `u64` can be expressed infallibly using `From`
- cast_possible_truncationcasting `u64` to `u8` may truncate the value
- cast_precision_losscasting `u64` to `f64` may cause a loss of precision (`u64` is 64 bits wide, but `f64`'s mantissa is only 52 bits wide)
- cast_ptr_alignmentcasting from `*const u8` to a more-strictly-aligned pointer (`*const u16`) (1 < 2 bytes)
- cast_sign_losscasting `i8` to `u64` may lose the sign of the value
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::too_many_linesChecks for functions with a large amount of linesRead it next →Did this answer your question?