Skip to content

YulUtilFunctions: reject _bytes == 0 in maskLowerOrderBytesFunction#16754

Open
msooseth wants to merge 1 commit into
developfrom
yulutilfunctions-mask-lower-order-bytes-nonzero-assert
Open

YulUtilFunctions: reject _bytes == 0 in maskLowerOrderBytesFunction#16754
msooseth wants to merge 1 commit into
developfrom
yulutilfunctions-mask-lower-order-bytes-nonzero-assert

Conversation

@msooseth
Copy link
Copy Markdown
Contributor

@msooseth msooseth commented May 20, 2026

Summary

  • maskLowerOrderBytesFunction(_bytes) asserts _bytes <= 32 but allows _bytes == 0.
  • For _bytes == 0, the mask expression (~u256(0)) >> (256 - 8 * _bytes) becomes ~0 >> 256 — implementation-defined in C++ and only happens to evaluate to 0 in boost's multiprecision::number<unchecked<…>>. The emitted Yul becomes result := and(data, 0x00), a zeroizer.
  • No current caller passes 0 (verified via grep), so this is not a current bug. Tighten the precondition to _bytes > 0 && _bytes <= 32 so future callers can't accidentally hit the degenerate case.
  • The dynamic variant maskLowerOrderBytesFunctionDynamic is unaffected — its Yul not(shl(mul(8, bytes), not(0))) formulation handles bytes == 0 correctly.

Test plan

  • CI builds clean (only tightens an existing assert).
  • No existing tests should regress since the new precondition is implied by current usage.

The existing assert allowed _bytes == 0, in which case the mask expression
(~u256(0)) >> (256 - 8 * _bytes) becomes (~0) >> 256 — implementation-defined
in C++ and only happens to yield 0 in boost::multiprecision. The generated
Yul would then become `result := and(data, 0x00)`, a zeroizer, which makes
no semantic sense for a "mask lower order bytes" helper. No caller passes 0
today; tighten the precondition so future callers can't accidentally trigger
the degenerate case.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant