GH-51223: [C++] Fix copying sliced boolean arrays - #51240
Conversation
|
|
There was a problem hiding this comment.
🟢 Approval recommended
The boolean ArraySpan copy now correctly accounts for slice offsets and the added regression tests directly cover the reported failure modes.
Pull request overview
Fixes incorrect bit indexing when copying from sliced boolean ArraySpans by ensuring the slice offset is applied during bitmap copies, and adds regression tests covering the affected compute kernels.
Changes:
- Apply
ArraySpan::offsetto the bit index when copying boolean values viaCopyDataUtils<BooleanType>. - Add regression tests for sliced boolean inputs in
replace_with_mask,fill_null_forward, andfill_null_backward.
File summaries
| File | Description |
|---|---|
| cpp/src/arrow/compute/kernels/copy_data_internal.h | Fix boolean ArraySpan copy to include in.offset in the bit index passed to CopyBitmap. |
| cpp/src/arrow/compute/kernels/vector_replace_test.cc | Add regression tests that exercise non-byte-aligned (offset=3) sliced boolean arrays for replace_with_mask and fill-null kernels. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Tested this against the reproducer from #51223: with the branch built locally, |
… verified against the reporter's reproducer Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
There was a problem hiding this comment.
🟢 Approval recommended
The fix correctly accounts for boolean slice offsets in the copy path and is backed by targeted regression tests for the reported failing kernels.
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
|
Thanks for validating this against the reproducer and for spotting the misplaced comment. Fixed in efb7d1f. |
| static void CopyData(const DataType&, const uint8_t* in, const int64_t in_offset, | ||
| uint8_t* out, const int64_t out_offset, const int64_t length) { | ||
| arrow::internal::CopyBitmap(in, in_offset, length, out, out_offset); | ||
| } |
There was a problem hiding this comment.
Is this one ever called directly without accounting for the input offset?
If so, then we must fix those use cases as well. Otherwise, perhaps make this method protected to avoid external usage?
There was a problem hiding this comment.
Yes, I checked the direct uses of the uint8_t* overload. They already pass an absolute bit offset, including the source ArraySpan::offset (for example, CopyValues in scalar_if_else.cc passes array.offset + in_offset).
The affected callers use the ArraySpan overload and pass an offset relative to that span, so adding in.offset there matches the fixed-width specializations and fixes the sliced boolean case. The raw-pointer overload still needs to remain accessible for callers that already supply an absolute offset.
…ibutor proposes the type fix on apache/arrow-go#1298
…ainer's offset question
pitrou
left a comment
There was a problem hiding this comment.
Thanks for the explanation @A-makarim . This looks good to me, I'll wait for additional CI and then we can merge.
Fixes apache#51223 Signed-off-by: Abdul Azeem Makarim <114302821+A-makarim@users.noreply.github.com>
efb7d1f to
398dcdf
Compare
|
Rebased. |
Rationale for this change
Boolean values are bit-packed. When copying values from a sliced boolean array,
the copy path did not include the array's slice offset. This caused
fill_null_forward,fill_null_backward, andreplace_with_maskto readvalues from earlier positions in the parent array.
What changes are included in this PR?
ArraySpan::offsetto the bit index when copying boolean values froman
ArraySpan.replace_with_mask,fill_null_forward, andfill_null_backward.Are these changes tested?
Yes. I ran
arrow-compute-vector-testlocally.Are there any user-facing changes?
Only a bugfix.
This PR contains a "Critical Fix".
This fixes a bug that caused compute operations on sliced boolean arrays with
a non-zero offset to produce incorrect values.