andygrove opened a new pull request, #1418: URL: https://github.com/apache/arrow-java/pull/1418
## What's Changed `DecimalVector` and `Decimal256Vector` have three public write paths that copy straight into native memory with `MemoryUtil`, bypassing `ArrowBuf` bounds checking: `setBigEndian(int, byte[])` (also reached via `setBigEndianSafe` and the generated `DecimalWriter.writeBigEndianBytesToDecimal(byte[])`), `setSafe(int, long, ArrowBuf, int)`, and `setBigEndianSafe(int, long, ArrowBuf, int)`. They bounds-check the destination slot but not the value length, so a value longer than `TYPE_WIDTH` overruns the slot. The `byte[]` variant throws only after copying; the `ArrowBuf` variants never throw. The `ArrowBuf` variants also sign-extend a zero-length value from the byte before `start`. This adds a `checkValueLength` guard that runs before any write in all three paths, removes the branches in `setBigEndian(int, byte[])` that the up-front check makes unreachable, and makes the `ArrowBuf` variants treat `length == 0` as a zero value, matching the `byte[]` variant. The existing exception message is unchanged. The new tests rely on the value buffer and validity buffer being adjacent slices of one allocation: each writes a `TYPE_WIDTH + 1` byte value into the last slot and asserts that an exception is thrown and that no validity bit was cleared. All four fail on `main` and pass with this change. The big-endian branches are covered by inspection only, as CI and my machine are little-endian. The fix and tests were written with the help of an AI coding assistant (Claude Code). I have reviewed every line of the generated code and verified the failing-then-passing behaviour of the tests locally. Closes #1417. -- 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]
