lz4frame favors the faster prefix mode
when decompressing a frame with linked blocks.
This significantly improved CLI decompression on files compressed with -BD4 setting.
On my laptop, decompressing `enwik9` went from 0.89s to 0.52s.
This improvement is only for linked blocks.
It's more visible for small block sizes.
* replace assert with test for LZ4F_uncompressedUpdate
* update documentation to incldue correct docstring
* remove unecessary entry point
* remove compress_linked_block_mode from fuzzing test
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
when the block mode changes a flush is executed, to prevent
mixing compressed and uncompressed data.
Prior to this commit dstStart, dstPtr, dstCapacity
where not updated to include the offset from bytesWritten.
For inputs > blockSize this meant the flushed data was
overwritten.
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
new method `uncompressed_update` allows to insert blocks without
compression into the lz4 stream.
The usage is documented in the frameCompress example
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
EndMark, the 4-bytes value indicating the end of frame,
must be `0x00000000`.
Previously, it was just mentioned as a `0-size` block.
But such definition could encompass uncompressed blocks of size 0,
with a header of value `0x80000000`.
But the intention was to also support uncompressed empty blocks.
They could be used as a keep-alive signal.
Note that compressed empty blocks are already supported,
it's just that they have a size 1 instead of 0 (for the `0` token).
Unfortunately, the decoder implementation was also wrong,
and would also interpret a `0x80000000` block header as an endMark.
This issue evaded detection so far simply because
this situation never happens, as LZ4Frame always issues
a clean 0x00000000 value as a endMark.
It also does not flush empty blocks.
This is fixed in this PR.
The decoder can now deal with empty uncompressed blocks,
and do not confuse them with EndMark.
The specification is also clarified.
Finally, FrameTest is updated to randomly insert empty blocks during fuzzing.
since Visual 2017,
worries about potential overflow, which are actually impossible.
Replaced (c * a) by (c ? a : 0).
Will likely replaced a * by a cmov.
Probably harmless for performance.
