home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 5 / FreshFish_July-August1994.bin / bbs / gnu / gzip-1.2.4-src.lha / src / amiga / gzip-1.2.4 / inflate.c < prev    next >
C/C++ Source or Header  |  1993-08-13  |  32KB  |  955 lines
  1. /* inflate.c -- Not copyrighted 1992 by Mark Adler
  2.    version c10p1, 10 January 1993 */
  3.  
  4. /* You can do whatever you like with this source file, though I would
  5.    prefer that if you modify it and redistribute it that you include
  6.    comments to that effect with your name and the date.  Thank you.
  7.    [The history has been moved to the file ChangeLog.]
  8.  */
  9.  
  10. /*
  11.    Inflate deflated (PKZIP's method 8 compressed) data.  The compression
  12.    method searches for as much of the current string of bytes (up to a
  13.    length of 258) in the previous 32K bytes.  If it doesn't find any
  14.    matches (of at least length 3), it codes the next byte.  Otherwise, it
  15.    codes the length of the matched string and its distance backwards from
  16.    the current position.  There is a single Huffman code that codes both
  17.    single bytes (called "literals") and match lengths.  A second Huffman
  18.    code codes the distance information, which follows a length code.  Each
  19.    length or distance code actually represents a base value and a number
  20.    of "extra" (sometimes zero) bits to get to add to the base value.  At
  21.    the end of each deflated block is a special end-of-block (EOB) literal/
  22.    length code.  The decoding process is basically: get a literal/length
  23.    code; if EOB then done; if a literal, emit the decoded byte; if a
  24.    length then get the distance and emit the referred-to bytes from the
  25.    sliding window of previously emitted data.
  26.  
  27.    There are (currently) three kinds of inflate blocks: stored, fixed, and
  28.    dynamic.  The compressor deals with some chunk of data at a time, and
  29.    decides which method to use on a chunk-by-chunk basis.  A chunk might
  30.    typically be 32K or 64K.  If the chunk is uncompressible, then the
  31.    "stored" method is used.  In this case, the bytes are simply stored as
  32.    is, eight bits per byte, with none of the above coding.  The bytes are
  33.    preceded by a count, since there is no longer an EOB code.
  34.  
  35.    If the data is compressible, then either the fixed or dynamic methods
  36.    are used.  In the dynamic method, the compressed data is preceded by
  37.    an encoding of the literal/length and distance Huffman codes that are
  38.    to be used to decode this block.  The representation is itself Huffman
  39.    coded, and so is preceded by a description of that code.  These code
  40.    descriptions take up a little space, and so for small blocks, there is
  41.    a predefined set of codes, called the fixed codes.  The fixed method is
  42.    used if the block codes up smaller that way (usually for quite small
  43.    chunks), otherwise the dynamic method is used.  In the latter case, the
  44.    codes are customized to the probabilities in the current block, and so
  45.    can code it much better than the pre-determined fixed codes.
  46.  
  47.    The Huffman codes themselves are decoded using a mutli-level table
  48.    lookup, in order to maximize the speed of decoding plus the speed of
  49.    building the decoding tables.  See the comments below that precede the
  50.    lbits and dbits tuning parameters.
  51.  */
  52.  
  53.  
  54. /*
  55.    Notes beyond the 1.93a appnote.txt:
  56.  
  57.    1. Distance pointers never point before the beginning of the output
  58.       stream.
  59.    2. Distance pointers can point back across blocks, up to 32k away.
  60.    3. There is an implied maximum of 7 bits for the bit length table and
  61.       15 bits for the actual data.
  62.    4. If only one code exists, then it is encoded using one bit.  (Zero
  63.       would be more efficient, but perhaps a little confusing.)  If two
  64.       codes exist, they are coded using one bit each (0 and 1).
  65.    5. There is no way of sending zero distance codes--a dummy must be
  66.       sent if there are none.  (History: a pre 2.0 version of PKZIP would
  67.       store blocks with no distance codes, but this was discovered to be
  68.       too harsh a criterion.)  Valid only for 1.93a.  2.04c does allow
  69.       zero distance codes, which is sent as one code of zero bits in
  70.       length.
  71.    6. There are up to 286 literal/length codes.  Code 256 represents the
  72.       end-of-block.  Note however that the static length tree defines
  73.       288 codes just to fill out the Huffman codes.  Codes 286 and 287
  74.       cannot be used though, since there is no length base or extra bits
  75.       defined for them.  Similarly, there are up to 30 distance codes.
  76.       However, static trees define 32 codes (all 5 bits) to fill out the
  77.       Huffman codes, but the last two had better not show up in the data.
  78.    7. Unzip can check dynamic Huffman blocks for complete code sets.
  79.       The exception is that a single code would not be complete (see #4).
  80.    8. The five bits following the block type is really the number of
  81.       literal codes sent minus 257.
  82.    9. Length codes 8,16,16 are interpreted as 13 length codes of 8 bits
  83.       (1+6+6).  Therefore, to output three times the length, you output
  84.       three codes (1+1+1), whereas to output four times the same length,
  85.       you only need two codes (1+3).  Hmm.
  86.   10. In the tree reconstruction algorithm, Code = Code + Increment
  87.       only if BitLength(i) is not zero.  (Pretty obvious.)
  88.   11. Correction: 4 Bits: # of Bit Length codes - 4     (4 - 19)
  89.   12. Note: length code 284 can represent 227-258, but length code 285
  90.       really is 258.  The last length deserves its own, short code
  91.       since it gets used a lot in very redundant files.  The length
  92.       258 is special since 258 - 3 (the min match length) is 255.
  93.   13. The literal/length and distance code bit lengths are read as a
  94.       single stream of lengths.  It is possible (and advantageous) for
  95.       a repeat code (16, 17, or 18) to go across the boundary between
  96.       the two sets of lengths.
  97.  */
  98.  
  99. #ifdef RCSID
  100. static char rcsid[] = "$Id: inflate.c,v 0.14 1993/06/10 13:27:04 jloup Exp $";
  101. #endif
  102.  
  103. #include <sys/types.h>
  104.  
  105. #include "tailor.h"
  106.  
  107. #if defined(STDC_HEADERS) || !defined(NO_STDLIB_H)
  108. #  include <stdlib.h>
  109. #endif
  110.  
  111. #include "gzip.h"
  112. #define slide window
  113.  
  114. /* Huffman code lookup table entry--this entry is four bytes for machines
  115.    that have 16-bit pointers (e.g. PC's in the small or medium model).
  116.    Valid extra bits are 0..13.  e == 15 is EOB (end of block), e == 16
  117.    means that v is a literal, 16 < e < 32 means that v is a pointer to
  118.    the next table, which codes e - 16 bits, and lastly e == 99 indicates
  119.    an unused code.  If a code with e == 99 is looked up, this implies an
  120.    error in the data. */
  121. struct huft {
  122.   uch e;                /* number of extra bits or operation */
  123.   uch b;                /* number of bits in this code or subcode */
  124.   union {
  125.     ush n;              /* literal, length base, or distance base */
  126.     struct huft *t;     /* pointer to next level of table */
  127.   } v;
  128. };
  129.  
  130.  
  131. /* Function prototypes */
  132. int huft_build OF((unsigned *, unsigned, unsigned, ush *, ush *,
  133.                    struct huft **, int *));
  134. int huft_free OF((struct huft *));
  135. int inflate_codes OF((struct huft *, struct huft *, int, int));
  136. int inflate_stored OF((void));
  137. int inflate_fixed OF((void));
  138. int inflate_dynamic OF((void));
  139. int inflate_block OF((int *));
  140. int inflate OF((void));
  141.  
  142.  
  143. /* The inflate algorithm uses a sliding 32K byte window on the uncompressed
  144.    stream to find repeated byte strings.  This is implemented here as a
  145.    circular buffer.  The index is updated simply by incrementing and then
  146.    and'ing with 0x7fff (32K-1). */
  147. /* It is left to other modules to supply the 32K area.  It is assumed
  148.    to be usable as if it were declared "uch slide[32768];" or as just
  149.    "uch *slide;" and then malloc'ed in the latter case.  The definition
  150.    must be in unzip.h, included above. */
  151. /* unsigned wp;             current position in slide */
  152. #define wp outcnt
  153. #define flush_output(w) (wp=(w),flush_window())
  154.  
  155. /* Tables for deflate from PKZIP's appnote.txt. */
  156. static unsigned border[] = {    /* Order of the bit length code lengths */
  157.         16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15};
  158. static ush cplens[] = {         /* Copy lengths for literal codes 257..285 */
  159.         3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 15, 17, 19, 23, 27, 31,
  160.         35, 43, 51, 59, 67, 83, 99, 115, 131, 163, 195, 227, 258, 0, 0};
  161.         /* note: see note #13 above about the 258 in this list. */
  162. static ush cplext[] = {         /* Extra bits for literal codes 257..285