mirror of
https://github.com/google/brotli.git
synced 2026-09-22 06:35:52 +00:00
A way to determine the decoded_buffer size? #441
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @maddsua on GitHub (Jan 7, 2023).
One needs to preallocate memory for output buffer when using
BrotliEncoderCompress()orBrotliDecoderDecompress().In case of encoding. there is a
BrotliEncoderMaxCompressedSize()function, which helps, but isn't so critical. In the worst case scenario, the compression ratio would be 1:1, so you only need to allocate the original data size + a little more for metadata.But when decompressing, I just realized that I don't have a way to determine the output buffer size. Sadly, it seems that there is no function to help, and guessing the size is definitely not gonna work for all cases.
The "one-shot memory-to-memory" operations are quite handy for stuff like HTTP compression, when the program already have all the data in memory, and that's actually what I use brotli in my project for.
At the moment, I use stream versions of encode/decode functions, wrapped in some completely unnecessary code. which I'd like to get rid of. There probably is an obvious solution to this problem, but I don't seem to find it.
TL:DR: How to get the space the data should take after decompression by
BrotliDecoderDecompress()?@eustas commented on GitHub (Jan 7, 2023):
Decompressed size could be indecently large. That is why there is no such functionality.
One-shot functions are more aimed for testing, where it is more or less known how large both input and output should be.
I'd be glad to remove those, but it is many years too late (since the initial release).
Sorry, that might me somewhat disappointing answer. Some new "one-shot" wrappers which does not require buffer size would be nice to have... but perhaps as a part of another project that covers multiple compression algorithms...
@maddsua commented on GitHub (Jan 8, 2023):
Thanks for your answer.
Would be really nice, if more projects provided that kind of easy to use wrappers. considering that they are actually pretty small. Like, in my project, it's < 200 lines of code (5KB) for both zlib and brotli.
Probably should make it as a library or something 😁