Zlib:deflate

сжимает столько данных, сколько возможно, и останавливается, когда входной буфер опустошается, или выходной буфер полностью заполняется. It may introduce some output latency (reading input without producing any output) except when forced to flush.

The detailed semantics are as follows. deflate выполняет одно или оба действия:

Перед вызовом deflate следует удостоверится, что как минимум одно из действий возмжно, by providing more input and/or consuming more output, and updating avail_in or avail_out accordingly; avail_out не должно быть нулём до вызова. The application can consume the compressed output when it wants, for example when the output buffer is full (avail_out == 0), or after each call of deflate. If deflate returns Z_OK and with zero avail_out, it must be called again after making room in the output buffer because there might be more output pending.
 * Compress more input starting at next_in and update next_in and avail_in accordingly. If not all input can be processed (because there is not enough room in the output buffer), next_in and avail_in are updated and processing will resume at this point for the next call of deflate.
 * Provide more output starting at next_out and update next_out and avail_out accordingly. This action is forced if the parameter flush is non zero. Forcing flush frequently degrades the compression ratio, so this parameter should be set only when necessary (in interactive applications). Some output may be provided even if flush is not set.

Normally the parameter flush is set to Z_NO_FLUSH, which allows deflate to decide how much data to accumulate before producing output, in order to maximize compression.

If the parameter flush is set to Z_SYNC_FLUSH, all pending output is flushed to the output buffer and the output is aligned on a byte boundary, so that the decompressor can get all input data available so far. (In particular avail_in is zero after the call if enough output space has been provided before the call.) Flushing may degrade compression for some compression algorithms and so it should be used only when necessary. This completes the current deflate block and follows it with an empty stored block that is three bits plus filler bits to the next byte, followed by four bytes (00 00 ff ff).

If flush is set to Z_PARTIAL_FLUSH, all pending output is flushed to the output buffer, but the output is not aligned to a byte boundary. All of the input data so far will be available to the decompressor, as for Z_SYNC_FLUSH. This completes the current deflate block and follows it with an empty fixed codes block that is 10 bits long. This assures that enough bytes are output in order for the decompressor to finish the block before the empty fixed code block.

If flush is set to Z_BLOCK, a deflate block is completed and emitted, as for Z_SYNC_FLUSH, but the output is not aligned on a byte boundary, and up to seven bits of the current block are held to be written as the next byte after the next deflate block is completed. In this case, the decompressor may not be provided enough bits at this point in order to complete decompression of the data provided so far to the compressor. It may need to wait for the next block to be emitted. This is for advanced applications that need to control the emission of deflate blocks.

If flush is set to Z_FULL_FLUSH, all output is flushed as with Z_SYNC_FLUSH, and the compression state is reset so that decompression can restart from this point if previous compressed data has been damaged or if random access is desired. Using Z_FULL_FLUSH too often can seriously degrade compression.

If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out), until the flush is complete (deflate returns with non-zero avail_out). In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that avail_out is greater than six to avoid repeated flush markers due to avail_out == 0 on return.

If the parameter flush is set to Z_FINISH, pending input is processed, pending output is flushed and deflate returns with Z_STREAM_END if there was enough output space; if deflate returns with Z_OK, this function must be called again with Z_FINISH and more output space (updated avail_out) but no more input data, until it returns with Z_STREAM_END or an error. After deflate has returned Z_STREAM_END, the only possible operations on the stream are deflateReset or deflateEnd.

Z_FINISH can be used immediately after deflateInit if all the compression is to be done in a single step. In this case, avail_out must be at least the value returned by deflateBound (see below). If deflate does not return Z_STREAM_END, then it must be called again as described above.

deflate sets strm->adler to the adler32 checksum of all input read so far (that is, total_in bytes).

deflate may update strm->data_type if it can make a good guess about the input data type (Z_BINARY or Z_TEXT). In doubt, the data is considered binary. This field is only for information purposes and does not affect the compression algorithm in any manner.

deflate возвращает Z_OK if есть какой-то прогресс (обработана порция входных данных или создана порция выходных), Z_STREAM_END если все входящие данные обработаны и все выходные созданы (только когда flush установлено в Z_FINISH), Z_STREAM_ERROR если состояние потока was inconsistent (к примеру next_in или next_out были NULL), Z_BUF_ERROR если прогресс невозможен (к примеру avail_in или avail_out были (стали?) нулём). Заметьте, что Z_BUF_ERROR не является фатальной ошибкой, и deflate может быть вызвана ещё раз,когда появятся входные данные и больше свободного места для выходных.