commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject [compress] BitInputStream
Date Wed, 12 Nov 2014 18:51:19 GMT
Hi

I wanted to write a few additional unit test for BitInputStream and
maybe later replace the zip package's BitStream with it (IMPLODE uses
that under the covers).

A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int - but
actually we can't do that as readBits returns -1 on EOF, so we can't
read more than 31 bits at a time or a valid read cannot be distinguished
from an EOF condition.  Fortunately 31 is the maximum of bits the LZW
implementations need.

One thing BitStream and BitInputStream have in common is what happens
when I request more bits than are available from the underlying stream,
both will signal an EOF and discard the cached bits.  I.e if there are
still three bits cached that haven't been read and I request four bits
I'll get a -1 rather than the three bits, I'm not sure this is the
correct behavior.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message