Arawoof06 opened a new issue, #50539: URL: https://github.com/apache/arrow/issues/50539
### Describe the bug, including details regarding any error messages, version, and platform. `castVARCHAR`/`castVARBINARY` from `date64` size their output block with a hard-coded 10 (`YYYY-MM-DD`), but the copy that follows is bounded by the caller-supplied length instead of by what was allocated. `arrow::internal::StringFormatter<Date64Type>` emits more than 10 bytes in two cases: years outside 0-9999 need 11-12 bytes, and values it cannot represent go through `detail::FormatOutOfRange`, which produces up to 42 bytes, e.g. `<value out of range: -9223372036854775808>`. So `castVARCHAR(<date64>, 64)` on an out-of-range value writes 42 bytes into a 10-byte arena block and sets `out_len` to 42, corrupting whatever the execution context hands out next. A test that performs the cast and then allocates again from the same context reads back: ``` <value out12345a12345-9223372036854775808> ``` The float macro has the same structure with a 24-byte constant; its formatter is documented to use a 50-byte buffer, so the same mismatch exists there even though current Java-style output happens to stay under 24. ### Component(s) C++ - Gandiva -- 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]
