mbutrovich opened a new issue, #11452: URL: https://github.com/apache/arrow-rs/issues/11452
### Describe the bug `test_i256_fuzz` fills a random number of low-order bytes, chosen with `rng.random_range(0..32)` ([mod.rs](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/mod.rs#L1647-L1661)). The range excludes 32, so byte 31, which holds the sign bit, is always zero. Every fuzz operand is non-negative and below 2^248, so the fuzz loop never reaches the sign handling in any operation that `test_ops` checks, such as the sign correction in [`i256::div_rem`](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/mod.rs#L488-L514). Negative operands come only from the fixed candidates in [`test_i256`](https://github.com/apache/arrow-rs/blob/c7f60c612bd16ca5485cc9acddfd216c10ea9765/arrow-buffer/src/bigint/mod.rs#L1584-L1615). @andygrove found this while reviewing #11425. ### To Reproduce Change `i256::div_rem` to return a floored remainder, which takes the sign of the divisor, instead of a truncated one. `test_i256_fuzz` still passes, and only `test_i256` fails. ### Expected behavior The fuzz operands should cover the whole `i256` range, including negative values. Choosing the length with `0..=32` and negating each operand with probability 1/2 does that. With that change the test passes on `main` and fails on the floored-remainder version above. ### Additional context Random bytes in all 32 positions give a random sign, but only for values near the top of the range. The random negation also covers small negative values. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
