-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encoding leads to other result than encoding with original c-source #1
Comments
Does the decompress of both encoding yield the original data ? If so it could be that the string search has picked different references to identical substrings, which should not affect the correctness of the library. If there is discrepancies in the decompressed data I will have to investigate. |
That's the result of
Decoding Here is my nushell output
When I encrypt Trying to decode this result with this library leads to a illegal backref error. The code of the test is below and the a screenshot of the result as well.
Greetings, Christian |
I found the problem. The C version fills a window buffer with 0 prior to compression, and allows searching in the full window. This means that the first run of 0s where referenced from before the start of input data. I have removed the IllegalBackref error and made it fetch 0 bytes instead to maintain compatibility. I have also added unit tests + fuzzing to verify this fix. Thanks for reporting this issue. I will close it once I have done some more testing and pushed an updated version. |
Fixed with release of version 0.2 |
Thank you for the quick fix! :-) |
You are welcome, and thank you for taking time to report the issue
I am curious what you are using heatshrink for? I gather it is for a WASM
target ? I think this is interesting, as I originally wrote it for some
embedded robotics applications, and so I would like to hear a little more
about how you use it if you are able to share any info.
Cheers,
Frank
…On Sun, Sep 10, 2023 at 9:01 PM ckrenslehner ***@***.***> wrote:
Thank you for the quick fix! :-)
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDNWZEAQ7BA5RFAUMQT5DXZYFBRANCNFSM6AAAAAA4C6PGOE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
We have some IoT devices in my company, and we basically use heatshrink for OTA firmware update file compression. We generate diff files using the jdiff algorithm and apply heatshrink afterward, which leads to an additional size reduction of 20% to 30%. Greetings, |
I have exactly the same reason for making my NodeJS binding. I'm also planning to make an another WebAssembly one for web browsers, that takes asset files in, bundles and creates a FAT32 image and compress it with Heatshrink, then push to an embedded target (ESP32 and RAM constrainted Linux boards) for further use. |
So if you can maybe provide some guidance relating to wasm and wasi I would be grateful! Or do you plan to write everything in pure rust? I discovered, that also using encrypt/decrypt https://crates.io/crates/aes-gcm is not straightforward in WASM context. Greetings, Christian |
@Krensi maybe try Zig? I remember Zig can handle some cross-compiling and binding stuff for C code, and it supports WASM/WASI as well. You may need to implement some glue code in Zig, expose the API you want and put in to your project. |
I am interested in Zig anyway so maybe I will give it a try. Anyway keep me updated about your wasm project if you plan to release it on GitHub. Sounds interesting! I am looking for projects to contribute because it is a great way of learning rust. |
-- Off topic -- https://wiki.seeedstudio.com/SeeedStudio_XIAO_Series_Introduction/ These are great! I can really recommend them |
Hi!
I wanted to use this library for decoding heatshrink compressed data. However, I was always getting an IllegalBackref error.
I decided to compare the encoding and decoding using the CLI (https://github.com/atomicobject/heatshrink) and the test data of the
alpha
test.So I guess something is wrong with the encoding? In both cases, a window size of 11 and a lookahead of 4 is used.
Result alpha test:
Result using CLI with same data:
Maybe you can tell me what I made wrong.
Regards, Christian
The text was updated successfully, but these errors were encountered: