X-Git-Url: https://wimlib.net/git/?a=blobdiff_plain;f=src%2Flzx-decompress.c;h=b7872520890135d8eee0db082746469e715122ba;hb=e176e9731e696562bab8de7b9bd34c019deef3e8;hp=ec8ccf25159fdc83fee6e85ddce47d64166145fe;hpb=35ff480326a41f7f74fe0a497c636a811922f276;p=wimlib diff --git a/src/lzx-decompress.c b/src/lzx-decompress.c index ec8ccf25..b7872520 100644 --- a/src/lzx-decompress.c +++ b/src/lzx-decompress.c @@ -28,31 +28,28 @@ /* * LZX is a LZ77 and Huffman-code based compression format that has many * similarities to the DEFLATE format used in zlib. The compression ratio is as - * good or better than DEFLATE. However, in WIM files only up to 32768 bytes of - * data can ever compressed be in the same LZX block, so a .tar.gz file could - * potentially be smaller than a WIM file that uses LZX compression because it - * can use a larger LZ77 window size. + * good or better than DEFLATE. * * Some notes on the LZX compression format as used in Windows Imaging (WIM) * files: * * A compressed WIM resource consists of a table of chunk offsets followed by * the compressed chunks themselves. All compressed chunks except possibly the - * last decompress to 32768 bytes. This is quite similar to the cabinet (.cab) - * file format, but they are not the same. According to the cabinet format - * documentation, the LZX block size is independent from the CFDATA blocks, and - * a LZX block may span several CFDATA blocks. However, in WIMs, LZX blocks do - * not appear to ever span multiple WIM chunks. Note that this means any WIM - * chunk may be decompressed or compressed independently from any other chunk, - * which is convenient. + * last decompress to a fixed number of bytes, by default 32768. This is quite + * similar to the cabinet (.cab) file format, but they are not the same. + * According to the cabinet format documentation, the LZX block size is + * independent from the CFDATA blocks, and a LZX block may span several CFDATA + * blocks. However, in WIMs, LZX blocks do not appear to ever span multiple WIM + * chunks. Note that this means any WIM chunk may be decompressed or compressed + * independently from any other chunk, which allows random access. * * A LZX compressed WIM chunk contains one or more LZX blocks of the aligned, * verbatim, or uncompressed block types. For aligned and verbatim blocks, the * size of the block in uncompressed bytes is specified by a bit following the 3 * bits that specify the block type, possibly followed by an additional 16 bits. - * '1' means to use the default block size (equal to 32768, the size of a WIM - * chunk--- and this seems to only be valid for the first LZX block in a WIM - * chunk), while '0' means that the block size is provided by the next 16 bits. + * '1' means to use the default block size (equal to 32768, the default size of + * a WIM chunk), while '0' means that the block size is provided by the next 16 + * bits. * * The cabinet format, as documented, allows for the possibility that a * compressed CFDATA chunk is up to 6144 bytes larger than the data it @@ -85,13 +82,13 @@ * defined in the specification. * * The LZX document states that aligned offset blocks have their aligned offset - * huffman tree AFTER the main and length trees. The implementation suggests + * Huffman tree AFTER the main and length trees. The implementation suggests * that the aligned offset tree is BEFORE the main and length trees. * * The LZX document decoding algorithm states that, in an aligned offset block, * if an extra_bits value is 1, 2 or 3, then that number of bits should be read * and the result added to the match offset. This is correct for 1 and 2, but - * not 3, where just a huffman symbol (using the aligned tree) should be read. + * not 3, where just a Huffman symbol (using the aligned tree) should be read. * * Regarding the E8 preprocessing, the LZX document states 'No translation may * be performed on the last 6 bytes of the input block'. This is correct. @@ -100,7 +97,7 @@ * would cause the next four bytes to be modified, at least one of which would * be in the last 6 bytes, which is not allowed according to the spec. * - * The specification states that the huffman trees must always contain at least + * The specification states that the Huffman trees must always contain at least * one element. However, many CAB files contain blocks where the length tree is * completely empty (because there are no matches), and this is expected to * succeed. @@ -193,10 +190,10 @@ read_huffsym_using_alignedtree(struct input_bitstream *istream, * code length values from the input. * * @istream: The bit stream for the input. It is positioned on the beginning - * of the pretree for the code length values. + * of the pretree for the code length values. * @lens: An array that contains the length values from the previous time - * the code lengths for this Huffman tree were read, or all - * 0's if this is the first time. + * the code lengths for this Huffman tree were read, or all + * 0's if this is the first time. * @num_lens: Number of length values to decode and return. * */ @@ -313,15 +310,15 @@ lzx_read_code_lens(struct input_bitstream *istream, u8 lens[], * * @istream: The input bitstream. * @block_size_ret: A pointer to an int into which the size of the block, - * in bytes, will be returned. + * in bytes, will be returned. * @block_type_ret: A pointer to an int into which the type of the block - * (LZX_BLOCKTYPE_*) will be returned. + * (LZX_BLOCKTYPE_*) will be returned. * @tables: A pointer to a lzx_tables structure in which the - * main tree, the length tree, and possibly the - * aligned offset tree will be constructed. + * main tree, the length tree, and possibly the + * aligned offset tree will be constructed. * @queue: A pointer to the least-recently-used queue into which - * R0, R1, and R2 will be written (only for uncompressed - * blocks, which contain this information in the header) + * R0, R1, and R2 will be written (only for uncompressed + * blocks, which contain this information in the header) */ static int lzx_read_block_header(struct input_bitstream *istream, @@ -494,9 +491,9 @@ lzx_read_block_header(struct input_bitstream *istream, istream->bitsleft = 0; istream->bitbuf = 0; } - queue->R[0] = le32_to_cpu(*(u32*)(istream->data + 0)); - queue->R[1] = le32_to_cpu(*(u32*)(istream->data + 4)); - queue->R[2] = le32_to_cpu(*(u32*)(istream->data + 8)); + queue->R[0] = le32_to_cpu(*(le32*)(istream->data + 0)); + queue->R[1] = le32_to_cpu(*(le32*)(istream->data + 4)); + queue->R[2] = le32_to_cpu(*(le32*)(istream->data + 8)); istream->data += 12; istream->data_bytes_left -= 12; /* The uncompressed data of this block directly follows and will @@ -521,14 +518,14 @@ lzx_read_block_header(struct input_bitstream *istream, * tree. * * @block_type: The type of the block (LZX_BLOCKTYPE_ALIGNED or - * LZX_BLOCKTYPE_VERBATIM) + * LZX_BLOCKTYPE_VERBATIM) * * @bytes_remaining: The amount of uncompressed data remaining to be - * uncompressed in this block. It is an error if the match - * is longer than this number. + * uncompressed in this block. It is an error if the match + * is longer than this number. * * @window: A pointer to the window into which the uncompressed - * data is being written. + * data is being written. * * @window_pos: The current byte offset in the window. * @@ -542,9 +539,9 @@ lzx_read_block_header(struct input_bitstream *istream, * * Returns the length of the match, or a negative number on error. The possible * error cases are: - * - Match would exceed the amount of data remaining to be uncompressed. - * - Match refers to data before the window. - * - The input bitstream ended unexpectedly. + * - Match would exceed the amount of data remaining to be uncompressed. + * - Match refers to data before the window. + * - The input bitstream ended unexpectedly. */ static int lzx_decode_match(unsigned main_element, int block_type, @@ -767,14 +764,14 @@ undo_call_insn_preprocessing(u8 uncompressed_data[], int uncompressed_data_len) * been read. * * @block_type: The type of the block (LZX_BLOCKTYPE_VERBATIM or - * LZX_BLOCKTYPE_ALIGNED) + * LZX_BLOCKTYPE_ALIGNED) * @block_size: The size of the block, in bytes. * @num_main_syms: Number of symbols in the main alphabet. * @window: Pointer to the decompression window. * @window_pos: The current position in the window. Will be 0 for the first - * block. + * block. * @tables: The Huffman decoding tables for the block (main, length, and - * aligned offset, the latter only for LZX_BLOCKTYPE_ALIGNED) + * aligned offset, the latter only for LZX_BLOCKTYPE_ALIGNED) * @queue: The least-recently-used queue for match offsets. * @istream: The input bitstream for the compressed literals. */ @@ -821,6 +818,7 @@ lzx_decompress_block(int block_type, unsigned block_size, return 0; } +/* API function documented in wimlib.h */ WIMLIBAPI int wimlib_lzx_decompress2(const void *compressed_data, unsigned compressed_len, void *uncompressed_data, unsigned uncompressed_len,