mzzz-zzm commented on issue #1027:
URL: https://github.com/apache/iceberg-go/issues/1027#issuecomment-4427121323
Confirmed numerically.
Across every realistic case I tested,
| precision | value | len | DRB(len) | DRB(precision) | match |
|-----------|-----------------|-----|----------|----------------|-------|
| 10 | "10.00" | 5 | 3 | 5 | ✗ |
| 10 | "1.00" | 4 | 2 | 5 | ✗ |
| 10 | "0.50" | 4 | 2 | 5 | ✗ |
| 10 | "1234567890.99" | 13 | 6 | 5 | ✗ |
| 18 | "1" | 1 | 1 | 8 | ✗ |
| 18 | "1.00" | 4 | 2 | 8 | ✗ |
| 38 | "1" | 1 | 1 | 16 | ✗ |
| 38 | "0.000000001" | 11 | 5 | 16 | ✗ |
So the bug actually triggers for all non-degenerate cases, not just some.
One inaccuracy in the report: the claim that `decimal(10,2) / 10.00` "produces
the right size by coincidence (`len("10.00") == 5 ==
DecimalRequiredBytes(10)`)" is wrong. `DRB(len("10.00")) = DRB(5) = 3`, not 5.
The report's own table actually shows 3 vs 5 for that row, contradicting its
prose. The bug bites that case too.
There is **no value that masks the bug** — `len(dec.String())` essentially
never equals `precision` for decimals with a decimal point, and `DRB(len) ==
DRB(precision)` requires collision within the lookup table, which doesn't
happen for any of the realistic cases checked.
So the bug is broader than the report itself states.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
