Re: [Classpath-inetlib] Problems in gnu.inet.util.LineInputStream and gnu.inet.util.CRLFInputStream

[Robert Mitchell]

Oops.  I had not thought about in.available returning 0.  I do think you need a maximum length, though, because there is no point in copying (and processing) the whole file. to return what will be less than 120 bytes in most cases.

 

On giving you a patch, I unfortunately do not have an easy access to diff:  unfortunately I do my development on Windows and do not have a Windows version of diff at this point.  I am attaching a version of the file with Unix style end of lines.  If that doesn't do what you need, let me know and I'll figure out something.

 

Bob M.

>>> Chris Burdess <address@hidden> 4/3/2005 4:47 AM >>>

Robert Mitchell wrote:

> The readLine method for LineInputStream contains the following code:
>  
>             len = in.available();
>             len = (len < MIN_LENGTH) ? MIN_LENGTH : len;
>
>  
> This has the effect of reading the entire wrapped stream in order to
> find one line.

Not according to the documentation for InputStream.available, unless
all the bytes in the stream are immediately available for reading, in
which case they will all be read.

> I suggest two changes.  First, the above lines should be replaced by:
>  
>             len = in.available();
>             len = (len > MIN_LENGTH) ? MIN_LENGTH : len;

and presumably changing the name of MIN_LENGTH to MAX_LENGTH?

It may be useful to specify both a minimum /and/ a maximum, but your
patch will cause problems when in.available() returns 0.

> Second, I am attaching a replacement for CRLFInputStream that corrects
> both the inefficiencies of removeCRLF and the problems with
> read(byte[], int, int).  The first is fixed by making sure to only
> copy bytes once to remove CR, instead of copying them for each CR
> removed ahead of them.  The second is fixed by passing the correct
> length to removeCRLF.  To avoid an infinite loop problem with a CR at
> the end of a buffer, it reads the next character instead of buffering
> the CR.  To avoid possible problems with mark/reset caused by this, it
> adds one to the requested readahead limit.  (Note this does not deal
> with potential problems with interactions between the single byte
> read() - which can read 2 bytes - and mark/reset.)

I'm interested in this, but please could you provide a patch against
the current source? The file you attached is encoded with CRs at the
end of every line so I can't diff it against the original.
--
Chris Burdess

CRLFInputStream.java
Description: Binary data