Michael Koch wrote:
Why is this distinction important? We are converting the result to chars (well, a String) anyway.Does anyone know why we use the custom "LineInputStream" class instead of, say, BufferedReader here? At one point BufferedReader.readLine() was buggy and could "read too much" and block before returning a line, but I believe we have fixed that. Code re-use would help to avoid bugs like this ;-)
Erm, because LineInputStream is an InputStream dealing with bytes, and BufferedReader is a Reader dealing with chars.
LineInputStream reads one byte and transforms it into an ascii character.
BufferedReader reads a char (2 bytes) as character.
As I said, this isn't really a big deal because we must convert to chars anyway, since we're returning a String. Using the BufferedReader, the conversion just happens at a different time.
However, Tromey did point out a good reason on IRC earlier today: BufferedReader.readLine() would read beyond the end of the headers on the underlying stream. Since the underlying stream may really be bytes and not characters, we need a mechanism to reset the stream back to the first byte after the headers when it reads past the last EOL.
Bryce
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
