- 01 1月, 2017 5 次提交
-
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
Also declare z_size_t when compiling solo.
-
由 Mark Adler 提交于
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 提交于
-
- 31 12月, 2016 10 次提交
-
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
Per request, but its utility is likely to be very limited. See the comments in zlib.h.
-
由 Mark Adler 提交于
-
- 05 12月, 2016 3 次提交
-
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
- 04 12月, 2016 12 次提交
-
-
由 Mark Adler 提交于
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 提交于
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 提交于
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 提交于
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 提交于
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 提交于
-
由 Mark Adler 提交于
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 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
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.
-
- 30 10月, 2016 1 次提交
-
-
由 Mark Adler 提交于
-
- 28 10月, 2016 1 次提交
-
-
由 Mark Adler 提交于
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.
-
- 27 10月, 2016 1 次提交
-
-
由 Mark Adler 提交于
-
- 26 10月, 2016 1 次提交
-
-
由 Mark Adler 提交于
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.
-
- 25 10月, 2016 3 次提交
-
-
由 Mark Adler 提交于
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.
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
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.
-
- 15 10月, 2016 3 次提交
-
-
由 Mark Adler 提交于
-
由 Mark Adler 提交于
This avoid defining a macro that is never used when not debugging.
-
由 Mark Adler 提交于
Recursive macro calls are normally caught by the preprocessor and avoided. This commit avoids the possibility of a problem entirely.
-