| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the initial intention was to update lz4f ring buffer strategy,
but lz4f doesn't use ring buffer.
Instead, it uses the destination buffer as much as possible,
and merely copies just what's required to preserve history
into its own buffer, at the end.
Pretty efficient.
This patch just clarifies a few comments and add some assert().
It's built on top of #528.
It also updates doc.
|
|\
| |
| | |
Faster decoding speed
|
| |
| |
| |
| |
| |
| |
| | |
also :
- fix a potential malloc error
- proper use of ALLOC macro inside lz4hc
- update html API doc
|
| |
| |
| |
| | |
clarifying parsing restrictions near end of block.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It occurred to me that the formula "The last 5 bytes are always
literals", on the list of "assumptions made by the decoder", is
remarkably ambiguous. Suppose the decoder is presented with 5 bytes.
Are they literals? It may seem that the decoder degenerates
to memcpy on short inputs. But of course the answer is no,
so the formula needs some clarification.
Parsing restrictions should be explained as well, otherwise they look
like arbitrary numbers. The 5-byte restriction has been mentioned
recently in connection with the shortcut in LZ4_decompress_generic,
so I add that. The second restriction is left to be explained
by the author.
I also took the liberty to explain that empty inputs "are either
unrepresentable or can be represented with a null byte". This wording
may actually have some merit: it leaves for the implementation,
as opposed to the spec, to decide whether the encoder can compress
empty inputs, and whether the decoder can produce an empty output
(which the implementation should further clarify).
|
| |
|
|
|
|
|
|
|
| |
Someone found it would be a great idea to define there a global variable under the very generic name "index".
Cause problem with shadow warnings, so no variable can be named "index" now ...
Also : automatically update API manual
|
|
|
|
| |
to clarify it includes potentially buffered data.
|
|
|
|
| |
updated NEWS was current progresses
|
|
|
|
|
| |
notably regarding LZ4_saveDict() speed advantage,
answering #477.
|
|
|
|
| |
answering question #473
|
|
|
|
|
| |
Also clarified a few API code comments
and updated associated html documentation
|
|\
| |
| | |
Minor change to LZ4 Frame format specification
|
| | |
|
| |
| |
| |
| | |
add new terms "LZ4 Frame Header" and "LZ4 Frame Footer"
|
|/
|
|
| |
to better reflect LZ4F API usage.
|
| |
|
|
|
|
|
| |
updated relevant doc.
This patch has no impact on ABI/API, nor on binary generation.
|
| |
|
|
|
|
|
| |
(synchronous bufferless mode)
answering questions by @jtbandes (#394)
|
|
|
|
|
| |
to be more compatible with reproducible builds.
patch inspired by @bmwiedemann
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Not obvious : copying the state was copying cdict's compression level
|
|
|
|
|
| |
note : only compression API is implemented and tested
still to do : decompression API
|
| |
|
|
|
|
|
| |
Compressor can set dictID on LZ4F_compressBegin()
Decompressor can retrieve it using LZ4F_getFrameInfo()
|
|
|
|
|
| |
Restored DictID field in Frame header
Bumped specification version to v1.6.0
|
| |
|
| |
|
| |
|
|
|
|
|
| |
due to addition of prototype
LZ4F_resetDecompressionContext()
|
|
|
|
|
| |
to automatically build manual files with
make all
|
| |
|
| |
|
| |
|
| |
|
|
|