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
Describe the bug, including details regarding any error messages, version, and platform.
castVARCHAR/castVARBINARYfromdate64size 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 throughdetail::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 setsout_lento 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: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