[patch] "\r\n" handling in DataInputStream.readLine()

[Bryce McKinlay]

Tom Tromey wrote:

> Bryce> The only case where this doesn't provide correct behaviour
> Bryce> would be if the user calls another DataInputStream method like
> Bryce> read() after calling readLine(), in which case they will still
> Bryce> get an '\n' sitting at the start of the stream.
>
> Couldn't you reset the flag in these methods?

Yes - this would be the ideal solution, and it would mean we could
remove the BufferedInputStream and mark() hacks from readLine().
However, I decided not to do this because of the following comment in
the readLine() method:

     // Either way,
     // this would increase the complexity of the non-deprecated methods

     // and since it is undesirable to make non-deprecated methods
     // less efficient, the following seems like the most reasonable
     // approach.

> Even better would be Mauve tests to test for all the corner cases.
> Then we could be sure we were really doing the right thing.

Actually, I havn't looked at Mauve yet, but I'll see what I can do. Is
there any documentation on how to write a Mauve-compliant test?

regards

  [ bryce ]