Decompression bug: padding bits not tracked, causing extra characters in output

[palguna26]

The compression logic pads the last byte with zero bits, but the decompression logic does not know how many bits are actually valid. As a result, padding bits are also decoded, which can produce extra (garbage) characters at the end of each decompressed chunk.

This leads to corrupted output where the decompressed file does not exactly match the original input.

[Santhosh-p653]

Since the compressed bitstream is padded to full bytes, how does the decoder know how many bits in the last byte are actually valid?

Could this cause padding bits to be decoded as extra characters?

[palguna26]

Good catch, that’s exactly the issue.

The compressor pads the last byte, but the decoder does not know how many bits are valid, so it reads padding as real data and produces extra characters.

I will fix this by storing the valid bit length or original chunk size and trimming during decompression.

[Santhosh-p653]

Good catch, that’s exactly the issue.

The compressor pads the last byte, but the decoder does not know how many bits are valid, so it reads padding as real data and produces extra characters.

I will fix this by storing the valid bit length or original chunk size and trimming during decompression.

Makes sense, storing the valid bit length per chunk sounds like the cleanest fix. That should fully eliminate the padding issue during decoding.

I can try implementing that if needed.