CODEWITHSUNDEEP
czlibinflate
MarcusJ
MarcusJ

Reputation: 159

How does FCHECK in zlib/RFC1950 work?

I'm trying to implement my own Inflater for my own PNG library (I know, don't reinvent the wheel blah blah blah, idc)

and I'm really struggling to understand how it's supposed to work, apparently it's supposed to be a multiple of 31 (in 5 bits, so always 31?), plus we're supposed to read from the least significant bit to the most significant, which is backwards from all the other formats I've seen previously, which is introducing some confusion too.

I tried reading the Zlib source code, but it was basically unreadable, and the RFC isn't all that specific about the "check code" (which is apparently the 5 least significant bits of the second byte of the zlib header, or the second byte of the iDAT/fDAT chuck data sections).

So my question is; How do I read it, how do I verify it, what do I do with it?

Edit: the check code is also called FCHECK in RFC 1950

Upvotes: 0

Views: 627

Answers (1)

Mark Adler
Mark Adler

Reputation: 112627

RFC 1950 says precisely and succinctly how to verify the header.

The FCHECK value must be such that CMF and FLG, when viewed as a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG), is a multiple of 31.

CMF is the first byte of the stream, and FLG is the second byte. So what else can I say? Take the first byte, multiply by 256, and add the second byte. If that number is not a multiple of 31, then the header is not valid.

Upvotes: 0

Related Questions