summaryrefslogtreecommitdiffstats
path: root/lib/lz4.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix Enum CastsW. Felix Handte2020-08-101-5/+5
| | | | Fixes `-Wsign-compare` issues.
* Remove dirty Field From LZ4_stream_tW. Felix Handte2020-08-061-10/+0
|
* Remove Extraneous Reset in LZ4_attach_dictionary()W. Felix Handte2020-08-051-6/+0
| | | | | Nothing internally sets dirty anymore. The only way to get that is if you use an uninitialized context, in which case your warranty is void anyways.
* Call LZ4_memcpy() instead of memcpy()Nick Terrell2020-08-031-36/+51
| | | | | | | | | `LZ4_memcpy()` uses `__builtin_memcpy()` to ensure that clang/gcc can inline the `memcpy()` calls in freestanding mode. This is necessary for decompressing the Linux Kernel with LZ4. Without an analogous patch decompression ran at 77 MB/s, and with the patch it ran at 884 MB/s.
* Merge pull request #860 from adeason/old-style-definitionsYann Collet2020-07-291-2/+2
|\ | | | | Avoid old-style function definitions
| * Avoid old-style function definitionsAndrew Deason2020-05-071-2/+2
| | | | | | | | | | | | | | Define 0-argument functions like foo(void) instead of foo(), in order to avoid a warning with -Wold-style-definition. This makes it easier to embed lz4.c in projects that compile with -Werror -Wold-style-definition.
* | Merge pull request #863 from Devernua/reducing_stack_usage_in_t_alignmentYann Collet2020-07-161-2/+2
|\ \ | | | | | | Reducing stack usage in _t_alignment checks
| * | Reducing stack usage in _t_alignment checksAleksandr Kukuev2020-05-111-2/+2
| | |
* | | avoid computing 0 offsets from null pointersAlexander Gallego2020-07-081-2/+2
|/ / | | | | | | | | | | | | | | | | | | Similar work in the kernel: https://patchwork.kernel.org/patch/11351499/ UBsan (+clang-10) complains about doing pointer arithmetic (adding 0) to a nullpointer. This patch is tested with clang-10+ubsan
* | Force inline small functions used by LZ4_compress_generic.Bartosz Taudul2020-01-161-6/+6
| |
* | fixed lz4hc assert errorYann Collet2019-12-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | faster decoding speed with VisualYann Collet2019-12-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | by enabling the fast decoder path. Visual requires a different set of macro constants to detect x86 / x64. On my laptop, decoding speed on x64 went up from 3.12 to 3.45 GB/s. 32-bit is less impressive, though still favorable, with speed increasing from 2.55 to 2.60 GB/s. So both cases are now enabled. Suggested by Bartosz Taudul (@wolfpld).
* | Have read_variable_length use fixed size typesNigel Tao2019-09-211-2/+6
|/ | | | | | | | | | Otherwise, the output from decoding LZ4-compressed input could be platform dependent. Also add a compile-time check to confirm the existing code's assumptions that, if <stdint.h> isn't used, then sizeof(int) == 4. Updates #792
* [LZ4_compress_destSize] Fix off-by-one errorNick Terrell2019-08-091-1/+1
| | | | | | | | | | PR#756 fixed the data corruption bug, but didn't clear `ip`. PR#760 fixed that off-by-one error, but missed the case where `ip == filledIp`, which is harder for the fuzzers to find (it took 20 days not 1 day). Verified this fixed the issue reported by OSS-Fuzz. Credit to OSS-Fuzz.
* Only Bump Offset When Attaching Non-Null DictionaryW. Felix Handte2019-08-061-15/+21
| | | | | We do want to bump, even if the dictionary is empty, but we **don't** want to bump if the dictionary is null.
* Add Attach Dict Debug LogW. Felix Handte2019-08-061-0/+4
|
* Make Attaching an Empty Dict Behave the Same as Using it DirectlyW. Felix Handte2019-08-061-14/+15
| | | | | | | | | | | | | | | | | | | When using an empty dictionary, we bail out of loading or attaching it in ways that leave the working context in potentially slightly different states. In particular, in some paths, we will cause the currentOffset to be non-zero, while in others we would allow it to remain 0. This difference in behavior is perfectly harmless, but in some situations, it can produce slight differences in the compressed output. For sanity's sake, we currently try to maintain a strict correspondence between the behavior of the dict attachment and the dict loading paths. This patch restores them to behaving identically. This shouldn't have any negative side-effects, as far as I can tell. When writing the dict attachment code, I tried to preserve zeroed currentOffsets when possible, since they benchmarked as very slightly faster. However, the case of attaching an empty dictionary is probably rare enought that it's acceptable to minisculely degrade performance in that corner case.
* silence msan warning when offset==0Yann Collet2019-08-061-64/+65
|
* Merge pull request #760 from terrelln/destSizeYann Collet2019-07-191-1/+1
|\ | | | | [LZ4_compress_destSize] Fix off-by-one error in fix
| * [LZ4_compress_destSize] Fix off-by-one error in fixNick Terrell2019-07-181-1/+1
| | | | | | | | | | | | | | The next match is looking at the current ip, not the next ip, so it needs to be cleared as well. Credit to OSS-Fuzz
* | Fix LZ4_attach_dictionary with empty dictionaryNick Terrell2019-07-181-1/+1
|/
* [LZ4_compress_destSize] Fix overflow conditionNick Terrell2019-07-171-1/+1
|
* [LZ4_compress_destSize] Fix rare data corruption bugNick Terrell2019-07-171-0/+30
|
* [LZ4_compress_destSize] Allow 2 more bytes of match lengthNick Terrell2019-07-171-1/+1
|
* Merge pull request #752 from terrelln/fuzzersYann Collet2019-07-161-8/+41
|\ | | | | [ossfuzz] Improve the fuzzers
| * [lz4] Fix bugs in partial decodingNick Terrell2019-07-151-8/+41
| | | | | | | | | | * Partial decoding could read a few bytes beyond the end of the input * Partial decoding returned an error with an empty output buffer
* | ensure conformance with custom LZ4_DISTANCE_MAXYann Collet2019-07-151-4/+9
|/ | | | | | | | | | | | | | It's now possible to select a custom LZ4_DISTANCE_MAX at compile time, provided it's <= 65535. However, in some cases (when compressing in byU16 mode), the new distance wasn't respected, as it used to implied that it was necessarily within range. Added a distance check for this case. Also : added a new TravisCI test which ensures that custom LZ4_DISTANCE_MAX compiles correctly and compresses correctly (relying on `assert()` to find outsized offsets).
* Remove an useless declarationSylvestre Ledru2019-07-041-1/+1
|
* Fix out-of-bounds read of up to 64 KB in the pastNick Terrell2019-06-281-2/+8
|
* restored FORCE_INLINEYann Collet2019-06-041-1/+0
|
* Merge pull request #717 from lz4/inplaceYann Collet2019-05-311-18/+18
|\ | | | | Added documentation and macro to support in-place compression and decompression
| * decompress: changed final memcpy() into memmove()Yann Collet2019-05-311-10/+13
| | | | | | | | for compatibility with in-place decompression scenarios.
| * some more minor conversion warnings fixesYann Collet2019-05-291-4/+4
| |
| * ensure lz4.h can be included with or without LZ4_STATIC_LINKING_ONLY in any ↵Yann Collet2019-05-291-0/+1
| | | | | | | | | | | | order ensure correct propagation of LZ4_DISTANCE_MAX
| * added comments and macros for in-place (de)compressionYann Collet2019-05-291-4/+0
| |
* | FAST_DEC_LOOP: only did offset check in specific condition.Chenxi Mao2019-05-311-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | When I did FAST_DEC_LOOP performance test, I found the offset check is much more than v1.8.3 You will see the condition check difference via lzbench with dickens test case. v1.8.3 34959 v.1.9.x 1055885 After investigate the code, we could see the difference. v.1.8.3 SKIP the condition check if if condition is true in: https://github.com/lz4/lz4/blob/v1.8.3/lib/lz4.c#L1463 AND below condition is true https://github.com/lz4/lz4/blob/v1.8.3/lib/lz4.c#L1478\ The offset check should be invoked. v1.9.3 The offset check code will be invoked in every loop which lead to downgrade. So the fix would be move this check to specific condition to avoid useless condition check. After this change, the call number is same as v1.8.3
* enable LZ4_FAST_DEC_LOOP build macro on aarch64/GCC by defaultGeorge Prekas2019-05-071-0/+5
|
* several minor style changes recommended by clang-tidyYann Collet2019-04-241-64/+73
|
* fixed read-after input in LZ4_decompress_safe()Yann Collet2019-04-191-28/+29
|
* re-enable FORCE_INLINEYann Collet2019-04-171-3/+0
| | | | was disabled for tests
* fix out-of-bound read within LZ4_decompress_fast()Yann Collet2019-04-171-2/+13
| | | | | | | | | | | and deprecate LZ4_decompress_fast(), with deprecation warnings enabled by default. Note that, as a consequence of the fix, LZ4_decompress_fast is now __slower__ than LZ4_decompress_safe(). That's because, since it doesn't know the input buffer size, it must progress more cautiously into the input buffer to ensure to out-of-bound read.
* Fix AIX errors/warningsNorm Green2019-04-171-0/+6
|
* simplified output_directiveYann Collet2019-04-151-15/+17
|
* fix comma for pedanticYann Collet2019-04-151-1/+1
|
* unified limitedOutput_directiveYann Collet2019-04-151-16/+15
| | | | | | | | | | | 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.
* fixed lz4frame with linked blocksYann Collet2019-04-151-11/+9
| | | | | | | when one block was not compressible, it would tag the context as `dirty`, resulting in compression automatically bailing out of all future blocks, making the rest of the frame uncompressible.
* fixed minor Visual warningsYann Collet2019-04-121-2/+2
| | | | | | | | 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.
* introduce LZ4_DISTANCE_MAX build macroYann Collet2019-04-111-15/+20
| | | | | | | | | | 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
* modified LZ4_initStreamHC() to look like LZ4_initStream()Yann Collet2019-04-091-0/+1
| | | | | it is now a pure initializer, for statically allocated states. It can initialize any memory area, and because of this, requires size.
* check some more initialization resultYann Collet2019-04-081-1/+5
| | | | ensure it's not NULL.
generated by cgit v0.12 at 2024-09-06 13:13:33 (GMT)