Anton Fernando
Anton Fernando

Reputation: 31

Should stream's next_in, the compressed buffer be available for inflatePrime() ? - zlib

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

Answers (1)

Mark Adler
Mark Adler

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

Related Questions