Lstarsky0 commented on issue #10788:
URL: https://github.com/apache/arrow-rs/issues/10788#issuecomment-5383985668
The divide-by-zero is `base.pow_wrapping(-exp)` at `parse.rs:896` evaluating
to exactly 0. `10^k == 2^k * 5^k`, so on an N-bit native `10^k mod 2^N` is 0
for every `k >= N` — Decimal32 hits it as soon as `-exp >= 32`.
What sets `-exp` is not the exponent in the literal. At `:881`/`:887` it
comes out as `scale - (fractionals - raw_exp)`, so the fractional digit count
drives it. On Decimal32 with precision 9, scale 0, input `1.<n ones>E-1`:
```
n = 30 -> Ok(0)
n = 31 -> panic, attempt to divide by zero
```
which is the predicted `n + 1 >= 32`. An exponent of `E-1` is enough to get
there.
The half I'd worry about more is the one that doesn't panic:
```rust
parse_decimal::<Decimal64Type>("1.11111111111111111111111111111111E-1", 18,
0) // Ok(1), should be 0
```
32 fractional digits, `-exp` is 33, and `pow_wrapping(33)` on `i64` is
nonzero garbage rather than zero, so it divides by garbage and returns without
complaint.
Why this is specific to e-notation: the main loop stops consuming fractional
digits at `fractionals == scale` (`:981`), so `1.<40 ones>` at scale 0 gives
`Ok(1)` correctly. `parse_e_notation` then goes back at `:815` and accumulates
every remaining fractional digit with no bound (`:824-829`). The guard at
`:889` only looks at the post-scaling digit count, so it never sees that the
accumulator swallowed 41 significant digits. That's also the type ladder in
your repro — `i256` is the only one wide enough to hold the mantissa before the
divide happens. For contrast, feeding the same 41 digits in without an exponent
is caught:
`parse_decimal::<Decimal128Type>("48250379364391354762609835314269495255615",
38, 0)` is a clean `Err`.
--
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]
