commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] BitInputStream
Date Thu, 13 Nov 2014 09:06:34 GMT
On 2014-11-13, Damjan Jovanovic wrote:

> On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig <> wrote:

>> 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.

> The (badly documented) assumption of readBits(final int count) is that
> exactly count bits must be successfully read, or it's a failure. For
> compression algorithms, these bits are symbols, and you can't do
> anything with half a symbol.

Understood.  But it's still not the behavior I'd expect :-)

Comparing that to the vanilla read(byte[]) method of InputStream the
method will tell me whether it has managed to read the full amount of
data I asked for and I as a caller can decide whether I want to accept a
partial result or not.  I'd prefer to have BitInputStream leave that
decision to the caller as well, but must admit I don't really like any
of the API ideas I can come up with right now (either return something
more complex than a plain int or add a parameter that tells readBits to
discard cached bits if it cannot fulfill my request).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message