- Jan 01, 2017
-
-
Mark Adler authored
-
- Dec 31, 2016
-
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
Also declare z_size_t when compiling solo.
-
Mark Adler authored
Limit read() and write() requests to sizes that fit in an int. This allows storing the return value in an int, and avoiding the need to use or construct an ssize_t type. This is required for Microsoft C, whose _read and _write functions take an unsigned request and return an int.
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
- Dec 30, 2016
-
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
Per request, but its utility is likely to be very limited. See the comments in zlib.h.
-
Mark Adler authored
-
- Dec 04, 2016
-
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
Normally these are set to size_t and ssize_t. But if they do not exist, then they are set to the smallest integer type that can contain a pointer. size_t is unsigned and ssize_t is signed.
-
Mark Adler authored
gzsetparams() was using Z_PARTIAL_FLUSH when it could use Z_BLOCK instead. This commit uses Z_BLOCK, which avoids emitting an unnecessary ten bits into the stream.
-
Mark Adler authored
In some cases the return values did not match the documentation, or the documentation did not document all of the return values. gzprintf() now consistently returns negative values on error, which matches the behavior of the stdio fprintf() function.
-
Mark Adler authored
The previous code slid the window and the hash table and copied every input byte three times in order to just write the data as stored blocks with no compression. This commit minimizes sliding and copying, especially for large input and output buffers. Level 0 compression is now more than 20 times faster than before the commit. Most of the speedup is due to deferring hash table slides until deflateParams() is called to change the compression level away from 0. More speedup is due to copying directly from next_in to next_out when the amounts of available input data and output space permit it, avoiding the intermediate pending buffer. Additionally, only the last 32K of the used input data is copied back to the sliding window when large input buffers are provided.
-
Mark Adler authored
This alters the specification in zlib.h, so that deflateParams() will not change any parameters if there is not enough output space in the event that a block is emitted in order to allow switching the compression function.
-
Mark Adler authored
-
Mark Adler authored
When debugging the Huffman coding would warn about resulting codes greater than 15 bits in length. This is handled properly, and is not uncommon. This increases the verbosity of the warning by one, so that it is not displayed by default.
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
-
Mark Adler authored
This speeds up level 0 by about a factor of three, as compared to the previous byte-at-a-time loop. We can do much better though. A later commit avoids this copy for level 0 with large buffers, instead copying directly from the input to the output. This commit still speeds up storing incompressible data found when compressing normally.
-
- Oct 30, 2016
-
-
Mark Adler authored
-
- Oct 28, 2016
-
-
Mark Adler authored
Compression level 0 requests no compression, using only stored blocks. When Z_HUFFMAN or Z_RLE was used with level 0 (granted, an odd choice, but permitted), the resulting blocks were mostly fixed or dynamic. The reason is that deflate_stored() was not being called in that case. The compressed data was valid, but it was not what the application requested. This commit assures that only stored blocks are emitted for compression level 0, regardless of the strategy selected.
-
- Oct 26, 2016
-
-
Mark Adler authored
-
- Oct 25, 2016
-
-
Mark Adler authored
This updates the OS_CODE determination at compile time to match as closely as possible the operating system mappings documented in the PKWare APPNOTE.TXT version 6.3.4, section 4.4.2.2. That byte in the gzip header is used by nobody for anything, as far as I can tell. However we might as well try to set it appropriately.
-
Mark Adler authored
This verifies that the state has been initialized, that it is the expected type of state, deflate or inflate, and that at least the first several bytes of the internal state have not been clobbered.
-
- Oct 24, 2016
-
-
Mark Adler authored
-
Mark Adler authored
There is a bug in deflate for windowBits == 8 (256-byte window). As a result, zlib silently changes a request for 8 to a request for 9 (512-byte window), and sets the zlib header accordingly so that the decompressor knows to use a 512-byte window. However if deflateInit2() is used for raw deflate or gzip streams, then there is no indication that the request was not honored, and the application might assume that it can use a 256-byte window when decompressing. This commit returns an error if the user requests a 256-byte window when using raw deflate or gzip encoding.
-
- Oct 14, 2016
-
-
Mark Adler authored
-
Mark Adler authored
This avoid defining a macro that is never used when not debugging.
-