David Daney wrote:
gnu.java.net.LineInputStream has at least one bug in it, but think its
whole approach is incorrect.
First the bug:
len = in.available();
len = (len MIN_LENGTH) ? MIN_LENGTH : len;
I think the idea was to read all available bytes into its buffer
Chris Burdess wrote:
David Daney wrote:
gnu.java.net.LineInputStream has at least one bug in it, but think its
whole approach is incorrect.
First the bug:
len = in.available();
len = (len MIN_LENGTH) ? MIN_LENGTH : len;
I think the idea was to read all available
Chris == Chris Burdess [EMAIL PROTECTED] writes:
I did take the liberty of adding my own micro-optimization, in that
if the encoding is US-ASCII, we can skip using String's character
encoding system and just request hibyte of 0. I did this because a
year ago with libgcj-3.4.3 we were
Tom Tromey wrote:
Chris == Chris Burdess [EMAIL PROTECTED] writes:
I did take the liberty of adding my own micro-optimization, in that
if the encoding is US-ASCII, we can skip using String's character
encoding system and just request hibyte of 0. I did this because a
year ago with
gnu.java.net.LineInputStream has at least one bug in it, but think its
whole approach is incorrect.
First the bug:
len = in.available();
len = (len MIN_LENGTH) ? MIN_LENGTH : len;
I think the idea was to read all available bytes into its buffer (but
not more that
