saleemno1 commented on code in PR #625:
URL: https://github.com/apache/commons-csv/pull/625#discussion_r3622208870
##########
src/main/java/org/apache/commons/csv/ExtendedBufferedReader.java:
##########
@@ -244,7 +275,16 @@ public int read(final char[] buf, final int offset, final
int length) throws IOE
if (length == 0) {
return 0;
}
- final int len = super.read(buf, offset, length);
+ int len = super.read(buf, offset, length);
+ // The underlying buffered reader stops early once the source reports
it is not ready, so a stream that delivers data in chunks (a socket or a pipe)
+ // yields a short read. Callers match multi-character sequences
against this buffer, so keep reading until it is full or the source is
exhausted.
Review Comment:
No, because the callers size the array to the exact sequence they're
matching. Lexer allocates `delimiterBuf` as `delimiter.length - 1` and
`escapeDelimiterBuf` as `2 * delimiter.length - 1`, so once the array is full
it holds the whole tail of the delimiter (or escaped delimiter), never a piece
of it. Same for `CSVFormat.printWithEscapes`, which peeks `delimiter.length -
1`.
The only way the loop exits short now is EOF, and then the remaining
characters genuinely don't exist, so no complete sequence can be there to miss.
Before the change the loop could exit short just because the source wasn't
ready yet, which is the case that broke.
--
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]
