[CSV-158] Fix EOL checking for read array in ExtendedBufferedReader

[mirasrael]

Characters in buffer before offset are unspecified

[britter]

Can you please explain some more what problems you're running into without this fix? A test case that fails without your change but is successful with this change would help me to understand this proposal.

[britter]

Placeholder JIRA ticket is https://issues.apache.org/jira/browse/CSV-158

[mirasrael]

You may not be sure buffer in call same as for previous read call. So you can just create new buffer without any initialization and call read method with non-zero offset. In this case character at position i-1 has undefined value. So you should check against offset for lastChar instead of zero.

[garydgregory]

Can you provide a unit test patch that shows the main code failing and then passing with this fix?

[mirasrael]

Without the fix getLineNumber method returns 3.

[britter]

@mirasrael thank you for the test. Things are getting clearer now. How would a CSV file look like which the parser fails to parse because of this bug?

[mirasrael]

Sorry. Its hard to remember where I face this bug, because I posted it year ago.

[britter]

@mirasrael yes I understand this and I'm very thankful that you reported it in the first case. I'm just trying to find out what the implications of applying this patch is. :-)

[dota17]

hi @britter after review the code，I think what @mirasrael means is that when use a new char[] buf and offset start from 5 in that way buf[0] to buf[4] are unspecified. so when i equals offset (that means i is 5) the expression (i > 0 ? buf[i - 1] : lastChar return buf[4] but what should return lastChar.

[garydgregory]

@mirasrael
Please rebase on git master to we can see new build results.

[mirasrael]

Updated for master

[garydgregory]

https://issues.apache.org/jira/browse/CSV-158