CODEWITHSUNDEEP
zlibdeflate
David Hankins
David Hankins

Reputation: 11

What is the meaning of the 3rd byte generated using zlib deflate?

What is the meaning of the 3rd byte generated using zlib deflate? (NO_FLUSH and Z_DEFAULT_COMPRESSION are being used in case that makes a difference).

The reason I'm asking is that I'm trying to exactly match the decompressed byte stream from an old (circa 2005) program using the current zlib library on Windows.

I'm able to exactly match the old program's output except that the initial bytes from the old program are

78 9C EC 9D ...

whereas the new library generates

78 9C ED 9D ...

As can be seen, the 3rd byte from the old program (EC) differs from the third byte from the new program (ED). However, every byte following the third exactly match (as does the zlib header).

Does anyone know:

  1. what the third byte means;
  2. whether the difference between EC and ED is going to impact inflation; and
  3. how to generate EC instead of ED using a current zlib library (I'd like to exactly match the old program's output.

Thanks in advance to responders.

Upvotes: 1

Views: 34

Answers (1)

Mark Adler
Mark Adler

Reputation: 112502

That bit is the "last" bit which when set (1) marks that first block as the last block in the deflate stream.

If you do not use Z_FINISH with the data you are compressing, that block will not be the last block and that bit will be a 0.

However then to complete the zlib stream, it will need to be followed by another block, now this one marked as the last block. So I don't understand "I'm able to exactly match the old program's output". They can't match if the zlib streams are valid.

Lastly: "I'm trying to exactly match the decompressed byte stream ...". Why? In general, this will not always even be possible, unless you have exactly the same compression code, the same version of that code, the same settings, and the same sequences of inputs and directions.

Upvotes: 0

Related Questions