ahlag opened a new pull request, #11661: URL: https://github.com/apache/arrow-rs/pull/11661
# Which issue does this PR close? Closes #11585. # Rationale for this change `StringArray::slice(n, 0)` keeps the offset it was sliced at as the array's single offset. When such an array is exported and imported again, `buffer_len` sizes the values buffer of an empty array at offset 0 as 0, because that lone offset can be any value from the producer (see `test_empty_string_with_non_zero_offset`). The offset itself was kept, so the imported `ArrayData` failed `validate_full` with `First offset 2 of Utf8 is larger than values length 0`. # What changes are included in this PR? In `ImportedArrowArray::consume`, an empty `Utf8`/`Binary`/`LargeUtf8`/`LargeBinary` array at offset 0 gets a zeroed offsets buffer, which matches the empty values buffer. Sizing the values buffer from the lone offset instead would read past the buffer for producers like the one in `test_empty_string_with_non_zero_offset` (offset 123 over an empty buffer). # Are these changes tested? Yes. `test_empty_slice_of_bytes` round-trips `slice(1, 0)` of each of the four types through `to_ffi`/`from_ffi`, then checks `validate_full` and equality with the exported data. It fails without the fix with the error above. `cargo test -p arrow-array --features ffi` and `--features ffi,force_validate` pass, and `cargo clippy -p arrow-array --all-targets --all-features -- -D warnings` is clean. # Are there any user-facing changes? No API changes. Empty sliced byte arrays imported through the C Data Interface now pass validation. AI use: Claude Code (AI) helped trace the import path and wrote the first draft of the fix, the test and this description; I reviewed and ran everything. -- 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]
