kaidokert / fixed-bigint-rs / 28763636231

97%

main: 97%

Pull #134

github

Address PR #134 review: zero-init BytesHolder, dedupe FromByteSlice length check

- `holder_be` / `holder_le` initialise via `BytesHolder::default()`
  (which zero-fills through the existing `ConstZero::ZERO` Default
  impl) instead of `BytesHolder::from_array(self.array)`. On the
  `&FixedUInt: ToBytes` path — the whole reason that impl exists —
  the old form read `self.array` through the reference and
  materialised a Copy of the secret limb array on the stack as the
  argument to `from_array`, then immediately overwrote it with the
  serialised bytes. That intermediate defeats the "no unwrapped
  secret on the stack" contract. Zero-init writes serialised bytes
  through the reference directly. Also drops a wasted Copy on the
  owned path.

  (gemini-code-assist inline finding, to_from_bytes.rs:197.)

- `FromByteSlice::from_be_slice` / `from_le_slice` route their
  empty + overflow length check through a shared crate-private
  `Self::check_slice_len` helper. Six lines to four, and future
  length-invariant changes only need to land in one place.

  (sourcery-ai general finding #2.)

sourcery-ai's general finding #1 — the stable and nightly
`ToBytes for &FixedUInt` impls take different code paths — is
declined for now. Stable uses `BytesHolder<T, N>` (unsafe
`from_raw_parts` reinterpretation over the limb storage) as the
associated type; nightly uses `ConstBytesHolder<{ byte_len::<T,N>() }>`
with a byte-by-byte const-eval-friendly loop. The two `Bytes`
associated types are structurally different — unifying would
require a shared abstraction that both variants can hit, more
churn than the divergence is worth on this hop. Revisit alongside
capability (c) in a follow-up.

62 of 68 new or added lines in 2 files covered. (91.18%)

3197 of 3280 relevant lines covered (97.47%)

302.83 hits per line