Copilot commented on code in PR #50483:
URL: https://github.com/apache/arrow/pull/50483#discussion_r3629909153
##########
cpp/src/arrow/csv/lexing_internal.h:
##########
@@ -138,6 +144,13 @@ class SSE42Filter {
_SIDD_UBYTE_OPS | _SIDD_CMP_EQUAL_ANY);
}
+ // _mm_cmpistrc is an implicit-length compare: it treats a NUL byte as a
+ // terminator and can miss a real delimiter/quote/newline sharing an 8-byte
+ // word with one. Never use this filter on a block that contains a NUL.
+ bool CanUseOnBlock(std::string_view data) const {
+ return data.empty() || std::memchr(data.data(), '\0', data.size()) ==
nullptr;
Review Comment:
The PR description (and linked issue) state the fix is switching SSE4.2
scanning from implicit-length `_mm_cmpistrc` to explicit-length `_mm_cmpestrc`,
but this code still uses `_mm_cmpistrc` and instead relies on pre-scanning
blocks for NUL bytes + disabling the bulk filter. Please either update the PR
description/tests to match the actual approach (including its perf/behavior
implications), or implement the `_mm_cmpestrc` change so NUL bytes are handled
without needing a full-block `memchr` scan and bulk-filter disable.
##########
cpp/src/arrow/csv/chunker_test.cc:
##########
@@ -341,6 +341,26 @@ TEST_P(BaseChunkerTest, EscapingAndQuoting) {
}
}
+TEST_P(BaseChunkerTest, EmbeddedNulBytesDisableBulkFilter) {
+ // Regression test for GH-50481 in Lexer's own bulk filter (used for
+ // chunking, separately from BlockParser's).
+ //
+ // Lead-in with no structural bytes so ShouldUseBulkFilter's probe of the
+ // first 256 bytes decides to use the bulk filter here.
+ std::string lead_in(300, 'x');
Review Comment:
This test name/comment hard-code the current mitigation
(“DisableBulkFilter”) instead of asserting the intended behavior (embedded NUL
bytes must not corrupt chunk boundaries). If the underlying SIMD filter is
fixed (e.g., explicit-length compares), the test should still read correctly
without implying bulk filtering must be disabled.
--
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]
