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

Question

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; 
}

Answer 1

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().