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>
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 4, 2026

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

@github-actions github-actions Bot added the stale The issue/PR was marked as stale because it has been open for too long. label Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale The issue/PR was marked as stale because it has been open for too long.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant