commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@apache.org>
Subject Re: [compress] BitInputStream
Date Wed, 12 Nov 2014 21:02:59 GMT
Le 12/11/2014 19:51, Stefan Bodewig a écrit :

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

Why not accumulating the bits in a long instead of an int?

Looking at BitInputStream I see it could precompute the bit masks like
BitStream, this is slightly faster.


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

If I remember well this is not supposed to happen with the implode
algorithm, unless the input stream is corrupted and in this case the EOF
is fine.

Emmanuel Bourg


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


Mime
View raw message