Skip to content
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

Report the offset at which "Unexpected EOF" error occured #221

Open
LorisSigrist opened this issue Aug 30, 2024 · 1 comment
Open

Report the offset at which "Unexpected EOF" error occured #221

LorisSigrist opened this issue Aug 30, 2024 · 1 comment

Comments

@LorisSigrist
Copy link

What can't you do right now?
I'm trying to process a buffer with sections that are compressed with deflate. I know where these sections start, but have no idea how long they are. I need to skip past these sections so I can continue processing the buffer.

If there were a way to know at which offset EOF happened I would be able to skip past these sections.

Example Buffer:

| plaintext data I want to read | deflated data of unknown length | plaintext data I want to read  | 

An optimal solution
Two possibilities:

  • The "Unexpected EOF" error reports the offset at which the file ended.
  • The inflate command succeeds with the decompressed data and tells you how many bytes remained unprocessed in the input.

How is this done by other libraries?
pako (which I'm currently using) doesn't fail when hitting the EOF. Instead it emits the decompressed data & has a value you can read the tells you how many bytes have remained unprocessed.

Eg. If you have a 150byte buffer and the first 100 are deflated-data, it will emit the decompressed data & tell you there are 50 bytes remaining.

@101arrowz
Copy link
Owner

The last time I tried something like this fflate just decompresses up to the end of the DEFLATE stream and no further, meaning it wouldn't provide an EOF error at all. I might be mistaken or maybe you're doing something differently than I'm imagining - could you send a code snippet I can use to reproduce the EOF error?

Regardless, you are right that there isn't a way to figure out how many compressed bytes have been read after decompression completes. This should be addressable in the streaming API without much difficulty, but it will not be added to the standard buffer-based API (to keep that API simple and bloat-free). Will look into it for the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants