Clippy lints / Nursery
Clippy lint · Nursery · checked with Clippy 0.1.99
clippy::read_zero_byte_vec: reading zero byte data to `Vec`
What it meansThis lint catches reads into a zero-length Vec. Especially in the case of a call to with_capacity, this lint warns that read gets the number of bytes from the Vec’s length, not its capacity. It is in the nursery group and off by default.
What you see
warning: reading zero byte data to `Vec` --> main.rs:6:5 | 6 | f.read(&mut data).unwrap(); | ^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#read_zero_byte_vec = note: `-W clippy::read-zero-byte-vec` implied by `-W clippy::nursery` help: try | 6 ~ data.resize(100, 0); 7 ~ f.read(&mut data).unwrap(); |
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?
Reading zero bytes is almost certainly not the intended behavior.
New lints still being finished. Off by default and may have false positives.
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
use std::io;
fn foo<F: io::Read>(mut f: F) {
let mut data = Vec::with_capacity(100);
f.read(&mut data).unwrap();
}
Write this instead
use std::io;
fn foo<F: io::Read>(mut f: F) {
let mut data = Vec::with_capacity(100);
data.resize(100, 0);
f.read(&mut data).unwrap();
}
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]
read_zero_byte_vec = "warn"In code
#![warn(clippy::read_zero_byte_vec)]One run
cargo clippy -- -W clippy::read-zero-byte-vecThe [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
This lint catches reads into a zero-length Vec.
Especially in the case of a call to with_capacity, this lint warns that read
gets the number of bytes from the Vec’s length, not its capacity.
Why is this bad?
Reading zero bytes is almost certainly not the intended behavior.
Known problems
In theory, a very unusual read implementation could assign some semantic meaning
to zero-byte reads. But it seems exceptionally unlikely that code intending to do
a zero-byte read would allocate a Vec for it.
Example
use std::io;
fn foo<F: io::Read>(mut f: F) {
let mut data = Vec::with_capacity(100);
f.read(&mut data).unwrap();
}
Use instead:
use std::io;
fn foo<F: io::Read>(mut f: F) {
let mut data = Vec::with_capacity(100);
data.resize(100, 0);
f.read(&mut data).unwrap();
}
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- redundant_cloneChecks for a redundant clone() (and its relatives) which clones an owned value that is going to be dropped without further use
- option_if_let_elseLints usage of if let Some(v) =
- or_fun_callChecks for calls to .or(foo(..)), .unwrap_or(foo(..)), .or_insert(foo(..)) etc., and suggests to use .or_else(|| foo(..)), .unwrap_or_else(|| foo(..)), .unwrap_or_default() or .or_default() etc
- path_buf_push_overwritecalling `push` with '/' or '\' (file system root) will overwrite the previous path definition
- redundant_pub_cratepub(crate) function inside private module
- search_is_somecalled `is_some()` after searching an `Iterator` with `find`
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::redundant_cloneChecks for a redundant clone() (and its relatives) which clones an owned value that is going to be dropped without further useRead it next →Did this answer your question?