Add tests to check data CRC#527
Conversation
Byron
left a comment
There was a problem hiding this comment.
Thanks a lot, I also think these will be very useful!
I'd wave the PR through, but then again, I have no clue. Maybe @folkertdev could take a look to see what he thinks might be missing. Based on this, we can decide if there should be more, or of that 'more' can or should be in another PR.
But maybe there are legitimate change requests as well, so I'd want to wait for his opinion.
folkertdev
left a comment
There was a problem hiding this comment.
Some minor style ideas/suggestions. Overall I think this gives good coverage of how flate2 uses checksums.
my PR additionally tests the public API (e.g. combine and reset). So together I think that would cover crc usage well.
|
Thanks a lot for chiming in @folkertdev! @jongiddy, I will wait until you had a chance to look at the suggestions, but generally will be happy to merge. |
The code currently has no tests for the data CRC. Add a test that the GzEncoders generate the CRC expected by RFC 1952 and that the GzDecoders fail if the CRC does not match.
|
Thanks for the great suggestions. I have applied them all. |
Byron
left a comment
There was a problem hiding this comment.
Thanks a lot everyone! I'd merge this.
However, please allow one last question: could these tests be in tests/ as they don't use private APIs? It looks like it, and I would have checked (and possibly done) the move myself but then I can't merge it anymore 😅.
Then again, as this doesn't introduce tests, we could also move the tests over, if possible, in a separate PR and call this one done enough.
|
The tricky part of moving to |
|
Ah, I see, thanks for clarifying. |
The code currently has no tests for the data CRC. Add a test that the GzEncoders generate the CRC expected by RFC 1952 and that the GzDecoders fail if the CRC does not match.
This will give us more confidence to make any changes to the CRC calculation (e.g. #523 or #526).