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 >> 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? which would only defer the problem. If you want to return -1 on EOF in a long, then you can't read more than 63 bits. :-) > Looking at BitInputStream I see it could precompute the bit masks like > BitStream, this is slightly faster. Yes, I thought the same. >> 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. Actually BitStream behaves differently, it will return the bits that have already been cached and return -1 on the next invocation. I think this is sane and should be sane for the compression use case as well. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
