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 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). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
