Unit InfBlock

Classes

Functions

inflate_blocks - window size

window size
inflate_blocks_free - check value on output

Case s.
inflate_blocks_new - infblock.
inflate_blocks_reset - initial return code

Notes beyond the 1.
inflate_blocks_sync_point - dictionary length

Returns true if inflate is currently at the end of a block generated by Z_SYNC_FLUSH or Z_FULL_FLUSH.
inflate_set_dictionary -

Types

Constants

Variables


Functions


function inflate_blocks (var s : inflate_blocks_state; var z : z_stream; r : int { initial return code } ) : int;

window size

window size


function inflate_blocks_free(s : pInflate_blocks_state; var z : z_stream) : int;

check value on output

Case s.mode of


function inflate_blocks_new(var z : z_stream; c : check_func; { check function } w : uInt { window size } ) : pInflate_blocks_state;

infblock.h and infblock.c -- interpret and process block types to last block Copyright (C) 1995-1998 Mark Adler Pascal tranlastion Copyright (C) 1998 by Jacques Nomssi Nzali For conditions of distribution and use, see copyright notice in readme.txt

check value on output


procedure inflate_blocks_reset (var s : inflate_blocks_state; var z : z_stream; c : puLong);

initial return code

Notes beyond the 1.93a appnote.txt: 1. Distance pointers never point before the beginning of the output stream. 2. Distance pointers can point back across blocks, up to 32k away. 3. There is an implied maximum of 7 bits for the bit length table and 15 bits for the actual data. 4. If only one code exists, then it is encoded using one bit. (Zero would be more efficient, but perhaps a little confusing.) If two codes exist, they are coded using one bit each (0 and 1). 5. There is no way of sending zero distance codes--a dummy must be sent if there are none. (History: a pre 2.0 version of PKZIP would store blocks with no distance codes, but this was discovered to be too harsh a criterion.) Valid only for 1.93a. 2.04c does allow zero distance codes, which is sent as one code of zero bits in length. 6. There are up to 286 literal/length codes. Code 256 represents the end-of-block. Note however that the static length tree defines 288 codes just to fill out the Huffman codes. Codes 286 and 287 cannot be used though, since there is no length base or extra bits defined for them. Similarily, there are up to 30 distance codes. However, static trees define 32 codes (all 5 bits) to fill out the Huffman codes, but the last two had better not show up in the data. 7. Unzip can check dynamic Huffman blocks for complete code sets. The exception is that a single code would not be complete (see #4). 8. The five bits following the block type is really the number of literal codes sent minus 257. 9. Length codes 8,16,16 are interpreted as 13 length codes of 8 bits (1+6+6). Therefore, to output three times the length, you output three codes (1+1+1), whereas to output four times the same length, you only need two codes (1+3). Hmm. 10. In the tree reconstruction algorithm, Code = Code + Increment only if BitLength(i) is not zero. (Pretty obvious.) 11. Correction: 4 Bits: # of Bit Length codes - 4 (4 - 19) 12. Note: length code 284 can represent 227-258, but length code 285 really is 258. The last length deserves its own, short code since it gets used a lot in very redundant files. The length 258 is special since 258 - 3 (the min match length) is 255. 13. The literal/length and distance code bit lengths are read as a single stream of lengths. It is possible (and advantageous) for a repeat code (16, 17, or 18) to go across the boundary between the two sets of lengths.


function inflate_blocks_sync_point(var s : inflate_blocks_state) : int;

dictionary length

Returns true if inflate is currently at the end of a block generated by Z_SYNC_FLUSH or Z_FULL_FLUSH. IN assertion: s <> Z_NULL


procedure inflate_set_dictionary(var s : inflate_blocks_state; const d : array of byte; { dictionary } n : uInt);


Types


Constants


Variables