| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
to remain similar to stdlib's calloc().
Updated test to use c++ compiler for stricter signature check.
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
detected by scan-build and cppcheck
fix #786
|
| |
|
|
| |
and fixed minor formatting warnings
|
| |
|
|
| |
Visual Studio seems to miss that they are necessarily initialized in the switch() { case: }
|
| |
|
|
|
| |
by for (;;)
just to please Visual Studio C4127 .
|
| |
|
|
|
|
|
|
|
| |
This emulates a streaming scenario,
where the caller follows rigorously the srcSize hints
provided as return value of LZ4F_decompress().
This is useful to show the issue in #714,
where data is uselessly copied in a tmp buffer first.
|
| |
|
|
| |
and created target cxx17build
|
| | |
|
| |
|
|
|
| |
it is now a pure initializer, for statically allocated states.
It can initialize any memory area, and because of this, requires size.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
- promoted LZ4_resetStream_fast() to stable
- moved LZ4_resetStream() into deprecate, but without triggering a compiler warning
- update all sources to no longer rely on LZ4_resetStream()
note : LZ4_initStream() proposal is slightly different :
it's able to initialize any buffer, provided that it's large enough.
To this end, it accepts a void*, and returns an LZ4_stream_t*.
|
| |
|
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
updated modification
|
| |
|
|
|
|
| |
as Makefile target and Travis CI test.
Fixed last cppcheck warnings in tests and examples
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
with a separated dictionary
since a joined dictionary is now detected as prefix64K.
Also : fixed a minor warning under msys
|
| |\
| |
| | |
Refactor dec
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Large File support for Mac OS-X in 32-bits mode
Fixed potential undefined behavior
Changed makefile for 32-bits mode
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
