[jira] [Commented] (CSV-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239052#comment-13239052 ] Emmanuel Bourg commented on CSV-75: --- I added a test demonstrating the issue. I wonder if the line counting should be handled by the lexer instead. ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239072#comment-13239072 ] Sebb commented on CSV-75: - Yes, perhaps it should be done by the lexer. But the quickest fix would be to patch the reader. I wonder whether ExtendedBufferReader is actually necessary; lookAhead() could easily be provided by the Lexer class. And I'm not sure that readAgain() is really necessary. ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239084#comment-13239084 ] Sebb commented on CSV-75: - Enabled new test and added patch to fix it. But we should still consider if ExtendedBufferReader is really necessary. ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
