Store HumanReadableNames in-object rather than on the heap
#3733
Conversation
|
👋 Thanks for assigning @valentinewallace as a reviewer! |
TheBlueMatt
force-pushed
the
2025-04-hrn-no-heap
branch
from
7f610cb to
4583457
Compare
|
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
| Err(_) => return Err(DecodeError::InvalidValue), | ||
| }; | ||
|
|
||
| let mut domain_bytes = [0; 255]; |
There was a problem hiding this comment.
Any reason to not use the 231 value mentioned above?
There was a problem hiding this comment.
It would make the below read_exact call able to panic if user_len is greater than 231 bytes. Seems simpler to expand stack a bit than bother checking it.
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
|
LGTM, feel free to squash |
TheBlueMatt
force-pushed
the
2025-04-hrn-no-heap
branch
from
eb86296 to
7365ed8
Compare
|
✅ Added second reviewer: @jkczyz |
Since the full encoded domain name of an HRN cannot exceed the maximum length of a DNS name (255 octets), there's not a lot of reason to store the `user` and `domain` parts of an HRN on the heap via two `String`s. Instead, here, we store one byte array with the maximum size of both labels as well as the length of the `user` and `domain` parts. Because we're now avoiding heap allocations this also implies making `HumanReadableName::new` take the `user` and `domain` parts by reference as `&str`s, rather than by value as `String`s.
TheBlueMatt
force-pushed
the
2025-04-hrn-no-heap
branch
from
7365ed8 to
7535a60
Compare
|
Just fixed the spelling issue: $ git diff-tree -U1 7365ed8f6 7535a6078
diff --git a/lightning/src/onion_message/dns_resolution.rs b/lightning/src/onion_message/dns_resolution.rs
index 58237bc29..df08787ad 100644
--- a/lightning/src/onion_message/dns_resolution.rs
+++ b/lightning/src/onion_message/dns_resolution.rs
@@ -190,3 +190,3 @@ const REQUIRED_EXTRA_LEN: usize = ".user._bitcoin-payment.".len() + 1;
/// If you intend to handle non-ASCII `user` or `domain` parts, you must handle [Homograph Attacks]
-/// and do punycode en-/de-coding yourself. This struc will always handle only plain ASCII `user`
+/// and do punycode en-/de-coding yourself. This struct will always handle only plain ASCII `user`
/// and `domain` parts. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3733 +/- ##
==========================================
+ Coverage 89.12% 89.83% +0.70%
==========================================
Files 156 156
Lines 123514 129420 +5906
Branches 123514 129420 +5906
==========================================
+ Hits 110086 116263 +6177
+ Misses 10749 10545 -204
+ Partials 2679 2612 -67 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4 participants
Since the full encoded domain name of an HRN cannot exceed the maximum length of a DNS name (255 octets), there's not a lot of reason to store the
useranddomainparts of an HRN on the heap via twoStrings.Instead, here, we store one byte array with the maximum size of both labels as well as the length of the
useranddomainparts.Because we're now avoiding heap allocations this also implies making
HumanReadableName::newtake theuseranddomainparts by reference as&strs, rather than by value asStrings.