stillwater-sc / universal / 26005819991

84%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(einteger): operator>>= leaves spurious limb past the shift boundary (#864)

operator>>=(int shift) had two latent bugs in the block-shift branch:

1. The inline zeroing inside the copy loop (`_block[i+blockShift] = 0`)
   only covered positions [blockShift, MSU].  When blockShift was bigger
   than (MSU+1)/2 -- i.e., the shift covered more than half the limb
   vector -- positions (MSU-blockShift, blockShift) were never touched
   and the original limb value leaked into the result.  Manifested
   visibly with uint8_t blocks, where any value above ~half a uint64_t
   needed enough limbs to trigger the gap.  Split the loop into a copy
   pass and an explicit zero pass that covers all the high positions
   uniformly.

2. The early-exit `if (shift > nbits())` missed the boundary case
   `shift == nbits()`.  At that boundary every significant bit shifts
   out, so the result must be zero, but the path fell through to the
   block-shift branch where `MSU < blockShift` skipped the inner copy
   loop and left the limbs untouched.  Tightened to `>=`.

New regression test `elastic/einteger/api/shift.cpp`:
- 15-byte payload (from issue #842's reproducer) shifted right by 64,
  24, and 17 across uint8_t / uint16_t / uint32_t block widths.
- shift == nbits and shift > nbits boundaries.
- The unaligned >> 17 case cross-checks against an independent
  integer<2048> reference computed via *= 256 + += digit, so the
  expected value isn't sampled from the implementation under test.

Resolves #862

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Coverage Stats

3 of 3 new or added lines in 1 file covered. (100.0%)

10 existing lines in 2 files now uncovered.

46750 of 55545 relevant lines covered (84.17%)

6418665.88 hits per line