Encoding/Decoding failing with -w 10

[svoulaz]

Hello - and thank you for the nice work!
I was planning to use the library in an embedded project, but trying it on desktop (develop branch built under wsl) I soon found a case in which encoding and decoding are not symmetrical.

Given the attached file, the compression output is as follows:
./heatshrink -e -v -w 10 test_input.dmp test_output.dmp
../test_input.dmp 46.42 % 153374 -> 82185 (-w 10 -l 4)

The subsequent decode output is as follows:
./heatshrink -d -v test_output.dmp decode_output.dmp
test_output.dmp -171.27 % 82185 -> 222945 (-w 11 -l 4)

The decoded file is indeed very different from the original file.
Am I missing something?

BR

test_input.dmp

[BenBE]

Encoding and decoding need to be performed with the same settings. Looking at the output you posted it seems that while encoding uses -w 10 (10 bit Window Size), the decoding uses -w 11 (11 bit Window Size) implicitly. This causes the decoding to interpret back-references in the compressed files differently and thus causing these differences when decoding.

[svoulaz]

Ah, ok - I thought the window was automatically detected. Great, that makes sense.
Thanks.

[silentbicycle]

BenBE is correct: It doesn't include the encoding/decoding configuration in the bytestream by design. Typically they would be passed out of band somehow, but the details there (header format, etc.) will likely to be project specific, so heatshrink itself just works with the raw stream and expects the caller is tracking the configuration.

When I get around to doing a new release I will call this out more explicitly in the docs.