Closed jongiddy closed 1 year ago
After fixing the bug, it took a few iterations to get the size of GzDecoder
back to its previous size. On 64-bit, write::GzDecoder<&mut [u8]>
is now 216 bytes (previously 224 bytes). Moving the header into bufread::GzState
makes bufread::GzDecoder<&[u8]>
176 bytes (previously 296 bytes).
Thanks for merging. It is a pleasant surprise when a well-aged PR finally gets merged. This patch has been running with no problems in our infrastructure for 9 months, so I'm reasonably confident that it is an improvement with no major downsides.
If the gzip header contains an optional filename or comment but they are not completely contained in the first buffer sent to a
write::GzDecoder
, then a valid header is created, missing data from these optional sections. A subsequent write call with the remaining header will treat the remaining header as encoded data and attempt to decode it, making the file appear to be corrupt.This change rewrites the header parsing code to handle partial headers correctly for both
Read
(whereWouldBlock
is handled specially) andWrite
(whereUnexpectedEof
is handled specially).The parsing code moves from
bufread.rs
tomod.rs
to emphasize that it is also used bywrite.rs
.write.rs
no longer uses any symbols frombufread.rs
.The only test in
bufread.rs
testedBuffer
which is no longer needed, so it was removed. The support code in thebufread
tests module was used by a test inmod.rs
which tests aread::GzDecoder
so the support code and the test move toread.rs
.Fixes #320