Reputation: 31
I noticed on 2nd boot up, when inflatePrime() is called, stream.next_in
doesn't have a compressed data buffer assigned yet, so how would it insert bits? (byte offset and bit offset, how they work to restart the inflation, is still bit unclear to me, here is my latest flow of things).
Thanks, appreciate any feedback.
////////// on 2nd boot:
// go to saved byte offset in compressed file
ZSEEK64(z_filefunc, filestream, streamCurrentPos, ZLIB_FILEFUNC_SEEK_SET);
if (streamBits)
{
int aByte=0;
unz64local_getByte(z_filefunc, filestream, &aByte));
inflatePrime (&stream, streamBits, aByte >> (8 - streamBits) );
}
inflateSetDictionary (&stream, dictionary_buf, dictLength);
// 'someSize' is BUF_SIZE or remaining rest_read_compressed
ZREAD64(z_filefunc, filestream, read_buffer, someSize);
stream.next_in = read_buffer;
stream.avail_in = someSize;
// on first call to inflate, gets data-error with "invalid code lengths set";
inflate(&stream, Z_BLOCK);
////////// on 1st boot: where 'state of uncompression' is saved
if ( (stream.data_type & 0x0080) && some_16MB_wrote_to_output) )
{
inflateGetDictionary(&stream, dictionary_buf, &dictLength);
streamBits = stream.data_type & (~0x1C0);
// current file pointer could be way ahead
streamCurrentPos = ZTELL64(z_filefunc, filestream) - stream.avail_in;
}
Upvotes: 0
Views: 106
Reputation: 112502
inflatePrime()
inserts bits into an internal buffer. It has nothing to do with next_in
or avail_in
, which can be changed before every call of inflate()
.
Upvotes: 0