signers subparser word uses the raw operand as row without & 0xFF masking (unlike signed-context)

[thedavidmeister]

Summary

The signers subparser word uses the raw operand as the signed-context signers ROW index, with no & 0xFF masking — unlike its sibling signed-context word, which masks both its column and row operand bytes with & 0xFF.

Verified on current main

• subParserSigners (src/lib/LibRaindexSubParser.sol:281):

  return LibSubParse.subParserContext(CONTEXT_SIGNED_CONTEXT_SIGNERS_COLUMN, uint256(OperandV2.unwrap(operand)));

  The full operand is the row, unmasked.
• subParserSignedContext (src/lib/LibRaindexSubParser.sol:397-398):

  uint256 column = uint256(OperandV2.unwrap(operand)) & 0xFF;
  uint256 row = (uint256(OperandV2.unwrap(operand)) >> 8) & 0xFF;

  Both masked to a byte.

So a signers operand > 255 passes a >255 row into subParserContext, where signed-context would wrap it to a byte.

Impact / triage

An inconsistency between two sibling words that build the same kind of context bytecode ([opIndex, ioByte, row, column], where row is a single byte). Surfacing for triage whether the unmasked signers row is intended, and whether subParserContext / the signers operand handler bounds the operand elsewhere (in which case the asymmetry is harmless but confusing). Low severity — the operand is author-controlled, so the worst case lands in the author's own expression.

Provenance

Surfaced by a blind adversarial review pass (code + spec only); verified independently against current main.

[linear]

RAI-874