diff options
author | Yann Collet <cyan@fb.com> | 2020-08-13 00:27:33 (GMT) |
---|---|---|
committer | Yann Collet <cyan@fb.com> | 2020-08-13 00:27:33 (GMT) |
commit | e9cfa49d0ddde238a7f3dbe6320f11e3d1fe58ea (patch) | |
tree | e1cf16ba087098aa80cc16572b6fc59e7e4b5065 /examples/dictionaryRandomAccess.c | |
parent | f328e329b3cec38ec8316d454279b79d19c36fdd (diff) | |
download | lz4-e9cfa49d0ddde238a7f3dbe6320f11e3d1fe58ea.zip lz4-e9cfa49d0ddde238a7f3dbe6320f11e3d1fe58ea.tar.gz lz4-e9cfa49d0ddde238a7f3dbe6320f11e3d1fe58ea.tar.bz2 |
Clarifies and fix EndMark
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.
Diffstat (limited to 'examples/dictionaryRandomAccess.c')
0 files changed, 0 insertions, 0 deletions