Hi Brian, I believe this looks good. I had to convince myself that there was no issue when '\r' is not followed by '\n' but I couldn't fault the logic.
I wonder if adding a third test case with '\r' not followed by '\n' would be a good idea? best regards, -- daniel On 26/04/2019 02:20, Brian Burkhalter wrote:
For issue [1] please review the patch [2]. The source change merely changes mark() to use a read ahead limit one value larger than the parameter if the most recently read character is a ‘\r’ (carriage return). In this case if the next character in the stream is a ‘\n’ (line feed), the next read() would actually consume two characters instead of one. The incremented read ahead limit compensates for this. The two sub-tests of the test both fail without the implementation change and succeed with it. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8218280 <https://bugs.openjdk.java.net/browse/JDK-8218280> [2] http://cr.openjdk.java.net/~bpb/8218280/webrev.00/
