MSVC (17.3 or earlier) reports the following warning
lz4\lib\lz4.c(527): warning C6385: Reading invalid data from 'v'.
Line 527 is : LZ4_memcpy(&v[4], v, 4);
But, obviously v[0..3] is always filled with meaningful value.
Therefore, this warning report is wrong.
We must revisit this issue with future version of MSVC.
designed to support specifically LZ4_decompress_fast*() variants.
The end goal is to offload this support from LZ4_decompress_generic
to improve its maintenance.
This changeset introduces new compile time switch macro LZ4_STATIC_LINKING_ONLY_DISABLE_MEMORY_ALLOCATION
which removes the following functions when it's defined.
```
// lz4.c
LZ4_createStream
LZ4_freeStream
LZ4_createStreamDecode
LZ4_freeStreamDecode
LZ4_create // legacy
// lz4hc.c
LZ4_createStreamHC(void)
LZ4_freeStreamHC
LZ4_createHC // legacy
LZ4_freeHC // legacy
```
These functions uses dynamic memory allocation functions such as malloc() and free().
It'll be useful for freestanding environment which doesn't have these allocation functions.
Since this change breaks API, this macro is only valid with lz4 as a static linked object.
This changeset introduces the following external macros.
- Add new macro LZ4_memset() which enables to inject external function as memset().
- Similar macro LZ4_memmove() for memmove().
- In same manner, LZ4_memcpy() also can be overriden by external macro.
The ARM64EC is a new Microsoft-designed ARM64 ABI that is compatible with AMD64 code. However, not all AMD64 intrinsic functions are supported. For, intrinsics that are lowered to AVX, AVX2 and AVX512 instructions are not supported, including the _tzcnt_u64. To make sure this file compiles for ARM64EC, the use of _tzcnt_u64 should be neutered.
This makes decoding significantly faster on M1; measured on compressed source
code across 8 hardware threads, decompressing 294 MB to 1301 MB takes 513 ms
of cumulative work (2.53 GB/s) before, and 406 ms (3.2 GB/s) after this change
on M1 Pro.
There's no way to check if the target architecture is M1 specifically but the
gains are likely to be similar on recent iterations on Apple processors, and
the original performance issue was probably more specific to Qualcomm.
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
coverity reported a warning regarding a memcpy() overwrite.
This is a false positive (the memory area is large enough),
but it's true that it's not trivial to determine (encompassing struct),
and it's proper anyway to only memcpy() just the right amount of data.
