Explicitly don't support ficticious architectures
What the developer wrote
Authored by Martin Habovstiak
Explicitly don't support ficticious architectures
Currently, no architecture with `usize` exists in stable or unstable
Rust or anywhere in the world that I (or ChatGPT) know of. Notably,
CHERI has 128 bit **pointers**, but **not** `usize`, which is still 64
bits.
Rather then producing garbage on such platforms it is much cleaner to
flat out not support them. This makes reviews easier to reason about and
removes the WTF factor. And while this appears breaking, it really isn't
becuase since no such platforms exist, nobody could've realied on this
behavior.
If such platforms ever arrive, this crate will be most likely EOL for
millenia but even then there exists upgrade path:
1. release 2.0 which has the `new` method behind a feature flag, off by
default
2. semver-trick the entire 2.0 with `*` import and the feature forced on
3. add `try_new` method that returns `Result`
Then downstream crates that want to support crazy-wide architecture will
just upgrade to 2.0 with the feature deactivated and use the new method.
What changed, and why it matters
This commit removes a fallback for extremely unusual (and currently non-existent) computer architectures where a memory-size value might be larger than 64 bits. On such hypothetical platforms, the old code would quietly cap the value at the maximum 64-bit number. The new code instead refuses to compile/run on those platforms, because none exist today. For every real platform, the behavior is unchanged.
No urgent action needed. Treat as a minor hardening/cleanup change. Reviewers should confirm that downstream callers do not rely on saturation behavior, though no real platform triggers it.
Security signals we found
Silent saturation of out-of-range length values replaced with explicit unsupported-platform assertion
Defensive hardening against hypothetical integer-width mismatch
No existing real architecture is affected
Evidence from the diff
In consensus_encoding/src/compact_size.rs, CompactSizeEncoder::new(usize) previously used u64::try_from(value).unwrap_or(u64::MAX), silently saturating a hypothetical >64-bit usize. The patch replaces that with a compile-time assertion that usize is at most 8 bytes and a plain value as u64 cast. This is a defensive correctness change: it turns a silent saturation bug on non-existent architectures into a build failure, making the supported-platform assumption explicit.
Changed components
consensus_encoding/src/compact_size.rsCompactSizeEncoder::newInspect captured patch +6 / −4
diff --git a/consensus_encoding/src/compact_size.rs b/consensus_encoding/src/compact_size.rs
index f76ecd00..3dee77e2 100644
--- a/consensus_encoding/src/compact_size.rs
+++ b/consensus_encoding/src/compact_size.rs
@@ -47,14 +47,16 @@ impl CompactSizeEncoder {
/// dominant use case for compact size encoding in the Bitcoin protocol. Prefer this constructor
/// whenever you are encoding the length of a collection or a byte slice.
///
- /// Compact size encodings are defined only over the `u64` range. On exotic platforms where
- /// `usize` is wider than 64 bits the value will be saturated to [`u64::MAX`], but in practice
- /// any in-memory length that could actually be passed here is well within the `u64` range.
+ /// Compact size encodings are defined only over the `u64` range. Hypothetical future platforms
+ /// that have `usize` greater than 64 bits are currently not supported.
///
/// If you need to encode an arbitrary `u64` integer that is not a length prefix, use
/// [`Self::new_u64`] instead.
pub fn new(value: usize) -> Self {
- Self { buf: Self::encode(u64::try_from(value).unwrap_or(u64::MAX)) }
+ const _WE_ONLY_SUPPORT_ARCHITECTURES_WITH_UP_TO_64_BIT_USIZE: () = {
+ assert!(core::mem::size_of::<usize>() <= 8);
+ };
+ Self { buf: Self::encode(value as u64) }
}
/// Constructs a new `CompactSizeEncoder` for an arbitrary `u64` integer.
Why this scored 18/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.