Hi, On Sun, 2003-11-02 at 21:11, Guilhem Lavaux wrote: > Mark Wielaard wrote: > > >OK. Let me try to summarize the behavior we want so we can at least > >create some good tests: > > > >DataInputStream.readLine(): > >- Should not block when it has seen at least a \r but return as soon as > > possible even when it cannot be sure that the next character is or > > isn't a \n to prevent programs from blocking/deadlocking. > >- If there is a unconsumed \n in the stream right after a readLine() > > then that \n should be transparently consumed for all these cases: > > - readLine() is called again. > > - another DataInputStream read method is called. > > - a non-overridden (Filter)InputStream is called. > > - a method in the originally wrapped InputStream is called. > > > >That will be an ugly nut to crack. Especially how to guarantee that last > >requirement is nasty. And the method is (rightly) deprectated since > >programmers should BufferedReader.readLine() anyway (specified since > >1.1). Sigh. > > > >But having a good test case will be very valuable start. > >Any volunteers :) > > > Well ! You described entirely the behaviour of the test. So it should be > considered as done. ;-)
I assume you are talking about test/regression/InputStreamTest.java from kaffe. I only briefly looked at it when the thread started and assumed it was only some strange corner case since it was also using the deprecated StringBufferInputStream (which has its own share of problems). Does that test really show all the (corner) cases that were discussed? (Especially when to wrapped InputStream is blocking just in the middle of a \r\n pair. Which seems to be the tricky case.) > But JDK won't pass this test (I've just tested > one or two pieces of the ideas). Actually if DataInputStream can detect > the '\n' it eats it directly in the call to readLine(). That is interesting. So that implementation probably just does some heuristics on the end of line if it can do it by looking ahead in the stream, but not otherwise. That is a very sneaky thing todo, but probably works in most cases that people care about. Sigh. What a bunch of yuck needed for such an ugly and deprecated method. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
