commit 5603d30f81c99fbe55f48d953e3df728720ff982
author Alexey Tourbin <alexey.tourbin@gmail.com> Thu Apr 26 07:46:26 2018 +0300
committer Alexey Tourbin <alexey.tourbin@gmail.com> Thu Apr 26 08:23:54 2018 +0300
tree a0c27174b8e5e9661f760ae86879c9f71790faf3
parent b4eda8d08f307dfc3cbd0d06baea4e6c581b70de

lz4.c: fixed the LZ4_decompress_safe_continue case

The previous change broke decoding with a ring buffer.  That's because
I didn't realize that the "double dictionary mode" was possible, i.e.
that the decoding routine can look both at the first part of the
dictionary passed as prefix and the second part passed via dictStart+dictSize.

So this change introduces the LZ4_decompress_safe_doubleDict helper,
which handles this "double dictionary" situation.  (This is a bit of
a misnomer, there is only one dictionary, but I can't think of a better
name, and perhaps the designation is not all too bad.)  The helper is
used only once, in LZ4_decompress_safe_continue, it should be inlined
with LZ4_FORCE_O2_GCC_PPC64LE attached to LZ4_decompress_safe_continue.

(Also, in the helper functions, I change the dictStart parameter type
to "const void*", to avoid a cast when calling helpers.  In the helpers,
the upcast to "BYTE*" is still required, for compatibility with C++.)

So this fixes the case of LZ4_decompress_safe_continue, and I'm
surprised by the fact that the fuzzer is now happy and does not detect
a similar problem with LZ4_decompress_fast_continue.  So before fixing
LZ4_decompress_fast_continue, the next logical step is to enhance
the fuzzer.