Derive `Copy` for `HumanReadableName`s
What the developer wrote
Authored by Matt Corallo
Derive `Copy` for `HumanReadableName`s
Now that these do not allocate, we should allow them to be
`Copy`ed.
What changed, and why it matters
This commit adds the Copy trait to a small, fixed-size data type used for human-readable payment names. Because the type no longer contains any heap-allocated data, making it Copy is a normal Rust API convenience. There is no security issue here.
No action needed. This is a benign API ergonomics change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch changes the derive macro for HumanReadableName from #[derive(Clone, Debug, Hash, PartialEq, Eq)] to #[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)]. The struct contains a fixed 255-byte byte array and a u8, so it is bitwise-copyable. Adding Copy is a safe, idiomatic Rust change once heap allocation was removed from the type.
Changed components
lightning/src/onion_message/dns_resolution.rsInspect captured patch +1 / −1
diff --git a/lightning/src/onion_message/dns_resolution.rs b/lightning/src/onion_message/dns_resolution.rs
index 9f88a7c..7961828 100644
--- a/lightning/src/onion_message/dns_resolution.rs
+++ b/lightning/src/onion_message/dns_resolution.rs
@@ -201,7 +201,7 @@ const REQUIRED_EXTRA_LEN: usize = ".user._bitcoin-payment.".len() + 1;
/// This struct can also be used for LN-Address recipients.
///
/// [Homograph Attacks]: https://en.wikipedia.org/wiki/IDN_homograph_attack
-#[derive(Clone, Debug, Hash, PartialEq, Eq)]
+#[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)]
pub struct HumanReadableName {
contents: [u8; 255 - REQUIRED_EXTRA_LEN],
user_len: u8,
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.