Closed nemequ closed 9 years ago
Yes it's a known behavior, decompression actually needs at least DENSITY_CHAMELEON_DECODE_MINIMUM_OUTPUT_LOOKAHEAD or DENSITY_MANDALA_DECODE_MINIMUM_OUTPUT_LOOKAHEAD bytes to continue processing. I don't know if this can be filed as a problem or not, because you just need a few hundred extra bytes or trick the decompressor into thinking it has the bytes available for everything to work properly. In your case, if you use LOREM_IPSUM_LENGTH + DENSITY_CHAMELEON_DECODE_MINIMUM_OUTPUT_LOOKAHEAD as the decompressed buffer length, everything will work, but I agree it's not ideal.
For a simple test case like this that would work, but there are plenty of cases where that's not feasible and you would really have no choice but to decompress to a temporary buffer then memcpy over to the real buffer. I would actually guess that most people who would be interested in the buffer to buffer API would fall into that case.
Maybe you could provide _fast and _safe versions of the API (kind of like LZ4, as well as some others)? Or tweak the implementation so that the last block decompresses to a temporary buffer if there is not enough space available to decompress it directly to the supplied buffer?
Implemented in 9e28aa59d586bc8fa7c80e85aff9c26fd6446bf5