On 2015-01-24, Stefan Bodewig wrote:
On 2015-01-23, Emmanuel Bourg wrote:
- BitInputStream: why not using a long cache instead of an int, like
BitStream before the refactoring? It might be interesting to do some
benchmarks and see if it make a difference.
We never needed more than 31 bits,
On 2014-11-12, Emmanuel Bourg wrote:
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
On 2014-11-13, Damjan Jovanovic wrote:
On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig bode...@apache.org 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
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 -
Apart from EOF handling there also is the byte-order case.
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
Should byte order imply we are always reading bytes in chunks of a given
number?
Right now I
On 2014-11-12, Stefan Bodewig wrote:
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
And it's not true, I just need to think about the returned ints in a
different way, all is fine :-)
Stefan
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
On Wed, Nov 12, 2014 at 9:49 PM, Stefan Bodewig bode...@apache.org wrote:
Apart from EOF handling there also is the byte-order case.
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
Should byte order
On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig bode...@apache.org 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
