| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
LZ4_streamHCPtr->internal_donotuse.end is NULL.
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
| |
makes it possible to replace at link time
malloc, calloc and free
by user-provided functions
which must be named LZ4_malloc(), LZ4_calloc() and LZ4_free().
answer #937
|
|
|
|
|
| |
- check alignment before casting a pointer
- saveDict : don't memmove() on NULL dst
|
|
|
|
|
| |
fix incorrect behavior of LZ4_saveDictHC()
when invoked right after initialization.
|
|\
| |
| | |
Revert "Replace "static" to "LZ4_FORCE_INLINE" for small functions"
|
| |
| |
| |
| | |
This reverts commit 0e3933edd435c54cc2e21e38f5d4ba7bf644a24e.
|
|/
|
|
|
|
|
| |
minor: identical declaration and prototypes of `LZ4HC_compress_optimal()`
also :
very minor optimization of `LZ4_memcpy_using_offset()`
|
|\
| |
| | |
More alignment tests
|
| |
| |
| |
| | |
across lz4.c and lz4hc.c
|
| |
| |
| |
| |
| | |
this it works fine in this environment
(only x86 is suspicious)
|
|\ \
| | |
| | | |
Fix: The "inline" specifier do not use for LZ4_wildCopy8 and LZ4_wildCopy32
|
| |/
| |
| |
| | |
The "static" specifier does not guarantee that the function will be inlined.
|
|/ |
|
| |
|
|
|
|
|
| |
detected by scan-build, cppcheck and advanved compilation flags
fix #786
|
|
|
|
| |
must respect MFLIMIT distance from oend
|
|
|
|
| |
after truncation of last sequence
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LZ4_compress_HC_destSize() had a tendency
to discard its last match when this match overflowed specified dstBuffer limit.
The impact is generally moderate,
but occasionally huge,
typically when this last match is very large
(such as compressing a bunch of zeroes).
Issue #784 fixed for both Chain and Opt implementations.
Added a unit test suggested by @remittor checking this topic.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when src ptr is in very low memory area (< 64K),
the virtual reference to data in dictionary
might end up in a very high memory address.
Since it's not a "real" memory address,
just a virtual one, to calculate distance,
it doesn't matter : only distance matters.
The assert was to restrictive.
Fixed.
|
| |
|
|
|
|
|
|
| |
When the match is very long and found quickly, we can do
matchLength * nbCompares iterations through the chain
swapping, which can really slow down compression.
|
|
|
|
|
|
| |
The pattern detection in extDict mode could put `matchIndex`
within the last 3 bytes of the dictionary. This would cause
a read out of bounds.
|
|
|
|
|
|
| |
We should be comparing `matchPtr` not `ip`. This bug just means
that this branch was not taken, so we might miss some of the
forward length.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is important to continue to look backwards if the current pattern
reaches `lowPrefixPtr`. If the pattern detection doesn't go all the
way to the beginning of the pattern, or the end of the pattern it
slows down the search instead of speeding it up.
The slow unit in `round_trip_stream_fuzzer` used to take 12 seconds
to run with -O3, now it takes 0.2 seconds.
Credit to OSS-Fuzz
|
|
|
|
| |
Fixes #761.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff fixes an issue in which we failed to clear the `dictCtx` in HC
compression. The `dictCtx` is not supposed to be used when an `extDict` is
present: matches found in the `dictCtx` do not account for the presence of an
`extDict` segment, and their offsets are therefore miscalculated when one is
present. This can lead to data corruption.
This diff clears the `dictCtx` whenever setting an `extDict`.
This issue was uncovered by @terrelln's fuzzing work.
|
|
|
|
| |
value of LZ4_DISTANCE_MAX,
|
| |
|
|
|
|
| |
and created target cxx17build
|
|
|
|
| |
as suggested by @sloutsky in #671
|
|
|
|
|
|
|
|
|
|
|
| |
between lz4.c and lz4hc.c .
was left in a strange state after the "amalgamation" patch.
Now only 3 directives remain,
same name across both implementations,
single definition place.
Might allow some light simplification due to reduced nb of states possible.
|
|
|
|
|
|
| |
yet some overly cautious overflow risk flag,
while it's actually impossible, due to previous test just one line above.
Changing the cast position, just to be please the thing.
|
|
|
|
|
|
|
|
|
|
| |
make it possible to generate LZ4-compressed block
with a controlled maximum offset (necessarily <= 65535).
This could be useful for compatibility with decoders
using a very limited memory budget (<64 KB).
Answer #154
|
|
|
|
|
| |
by making a full initialization
instead of a fast reset.
|
|
|
|
|
| |
it is now a pure initializer, for statically allocated states.
It can initialize any memory area, and because of this, requires size.
|
| |
|
|
|
|
|
|
|
|
| |
- promoted LZ4_resetStreamHC_fast() to stable
- moved LZ4_resetStreamHC() to deprecated (but do not generate a warning yet)
- Updated doc, to highlight difference between init and reset
- switched all invocations of LZ4_resetStreamHC() onto LZ4_initStreamHC()
- misc: ensure `make all` also builds /tests
|
|
|
|
| |
are changed by the function call
|
|
|
| |
Every 0xff byte in the compressed block corresponds to a length of 255 (not 256) in the input data. For long repeating sequences, using (length >> 8) may generate bad compressed blocks.
|
| |
|