perf: optimize Vec creation in bip152 tests
What changed, and why it matters
This is a tiny performance-only change inside test code. It swaps one way of creating a zero-filled vector for another equivalent but slightly faster method. It does not touch production code, user-facing behavior, or security logic.
No security action needed. Treat as a normal code-quality/test-performance improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In bitcoin/src/bip152.rs test module, the commit replaces [0u8; 32].to_vec() with vec![0u8; 32]. Both produce a 32-byte vector of zeros; the latter avoids an intermediate array copy and is idiomatic. The change is confined to a unit test and has no effect on runtime consensus or network code.
Changed components
bitcoin/src/bip152.rs (test module only)Inspect captured patch +1 / −1
diff --git a/bitcoin/src/bip152.rs b/bitcoin/src/bip152.rs
index 026d7e18..3c018caf 100644
--- a/bitcoin/src/bip152.rs
+++ b/bitcoin/src/bip152.rs
@@ -544,7 +544,7 @@ mod test {
for testcase in testcases {
{
// test deserialization
- let mut raw: Vec<u8> = [0u8; 32].to_vec();
+ let mut raw: Vec<u8> = vec![0u8; 32];
raw.extend(testcase.0.clone());
let btr: BlockTransactionsRequest = deserialize(&raw.to_vec()).unwrap();
assert_eq!(testcase.1, btr.indexes);
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.