- May 31, 2015
-
-
Scott Vokes authored
-
- May 24, 2015
-
-
Scott Vokes authored
As reported by @unixdj, there is a case where a few bytes can be dropped from the end of the bytestream when used with a window_sz2 of 4 and lookahead_sz2 of 2 (-w 4 -l 2): $ echo -n aaaa | ./heatshrink -e -w4 -l2 | ./heatshrink -d -w4 -l2 a # should be "aaaa" While st_check_for_input can treat 7 bits as sufficient input when -w is 4 and -l is 2, that creates a corresponding issue where 1 spillover bit from the previous byte leads to filler of 0b000 0000, which is interpreted as a marker to repeat (0b0) from 1 byte back (0b0000) for 1 byte (0b00), leading to a duplication of the last byte of input. Using a w,l pair where w+l < 7 leads to trailing bits that are ambiguous, so raise the minimum lookahead bits to 3. This problem does not occur with -w 4 -l 3, or any other valid config.
-
Scott Vokes authored
This is to ensure the full state space is explored. malloc (and re-use, after zeroing) large in-memory buffers for use in the tests, as these will not potentially fill the way smaller stack-allocated ones can.
-
Scott Vokes authored
-
- May 14, 2015
-
-
Scott Vokes authored
Thanks to @unixdj for finding this bug and providing very detailed info about how to reproduce it!
-
- May 11, 2015
-
-
Vadim Vygonets authored
-
Scott Vokes authored
Minor change for C99 compliance for an old compiler. no behavior changes
-
- May 08, 2015
-
-
Far McKon authored
-
- Jan 03, 2015
-
-
Scott Vokes authored
Main changes: 1) Several portability improvements for Windows/MinGW and other platforms. Thanks Phil Pemberton, Steffen Jaeckel. 2) Significant improvement of the Makefile / build setup, to make switching between builds of heatshrink using static or dynamic allocation easier. 3) Added property-based tests (Optional; depends on theft) to the test suite.
-
Scott Vokes authored
-
Scott Vokes authored
i.e., libheatshrink_dynamic.a and libheatshrink_static.a, which use dynamic allocation and static allocation (as configured), respectively. Build both, both test suites, and the command line tool. Get rid of the default "make" target that just suggested modifying the config and building one or the other. Add 'make install' and 'make ci' targets.
-
Scott Vokes authored
Fix implicit getopt
-
Scott Vokes authored
Fix a number of Windows-specific issues
-
- Dec 31, 2014
-
-
Philip Pemberton authored
-
Phil Pemberton authored
-
Phil Pemberton authored
All status messages should go out on stderr in case we're piping compressed data to other processes. Otherwise those errors might end up silently dumped into the data stream, and the error may go unnoticed.
-
Phil Pemberton authored
On Windows, stdin and stdout are opened in text mode. We need to reopen them in binary mode in case users are piping compressed data around.
-
Phil Pemberton authored
On Windows, binary files must be opened with the O_BINARY flag. On other platforms, O_BINARY isn't even defined. This resolves #9.
-
Phil Pemberton authored
Port Steffen Jaeckel's fix from sjaeckel/heatshrink commit a98ba4612... to the latest Heatshrink source.
-
- Sep 19, 2014
-
-
Scott Vokes authored
-
- Jun 26, 2014
-
-
Scott Vokes authored
-
Scott Vokes authored
-
Scott Vokes authored
-
Scott Vokes authored
- Jun 25, 2014
-
-
Scott Vokes authored
If the decompression stream was terminated with a 1 bit at exactly the byte boundary (perhaps due to decompressing from flash memory and sinking erased 0xFF bytes until the end of a flash page), it could end up in a state where heatshrink_decoder_finish() would return HSDR_FINISH_MORE, but calling heatshrink_decoder_poll would always yield 0 bytes of output. If _both_ results were not checked, this could lead to the code driving them uselessly calling them in a loop. Added regression test case: decoder_should_not_get_stuck_with_finish_yielding_MORE_but_0_bytes_output_from_poll Resolved by explicitly checking remaining input length in heatshrink_decoder_finish in the HSDS_YIELD_LITERAL state, since it is not safe to assume that the decompression stream input will be padded with 0 bits.
-
- Mar 25, 2014
-
-
Scott Vokes authored
-
- Jan 14, 2014
-
-
Scott Vokes authored
Only check for matches that can be improvements.
-
Scott Vokes authored
Only test whether len is > match_maxlen when at least the first byte matches, and use a pointer to curry in the current offset, saving an add per compare.
-
Scott Vokes authored
This eliminates more unnecessary compares, speeding things up further. (Thanks to user jibsen on hacker news for the original suggestion.)
-
- Dec 28, 2013
-
-
Scott Vokes authored
-
Scott Vokes authored
Also, update index type to int16_t.
-
Scott Vokes authored
-
Scott Vokes authored
Eliminate some unnecessary comparisons by making the position in the index signed, and treating any negative value as not found, not just ((uint16_t)-1). Also, decrease HEATSHRINK_MAX_WINDOW_BITS to 15, so index values with the highest bit set can be used as working space for index optimization on the fly (some day). Use 'if length >= 3' instead of 'length > 2' for the break even point, sinec it makes the intent clearer, and pull the comparison outside of the inner loop. Increase HEATSHRINK_MIN_LOOKAHEAD_BITS to 2, since -l 1 won't compress. Also, eliminate the corresponding MAX #define, since it has to be <= the window size anyway. Use a separate *pt == *pt2 instead of pt[0] == pt2[0] for comparison of the leading byte, which should allow for better branch prediction. Eliminate 'needle_index' in the inner loop -- it's only aliasing 'end'. Also, add comments about the indexing strategy.
-
Scott Vokes authored
This can save a significant amount of time in push_bits, particularly if -w is 8.
-
Scott Vokes authored
-
Scott Vokes authored
1. Instead of storing an offset to the previous matching byte in the index, store the next matching byte bigram. Since the compression doesn't break even unless at least 3 bytes match, any single-byte matches in the index should just be skipped. Since this eliminates these false positives in one pass, it also removes work that would otherwise be done during every walk of the index's offset chain - possibly several times. This greatly reduces the time spent in find_longest_match(). EDIT: This prematurely discards information from the index, damaging the overall compression effectiveness. Some of the links being skipped are still necessary for other chains, so they cannot be eliminated this way. It's still possible dynamic programming can be used for this, but the strategy in this commit doesn't quite work. 2. Eliminate the test of the first byte, since indexing already incorporates this comparison ahead of time.
- Dec 21, 2013
-
-
Scott Vokes authored
-
- Dec 19, 2013
-
-
Scott Vokes authored
*comment on rebase*
-