/*
* 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
* 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.
* 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.
* 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.
*
*/
*
* @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,
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
* 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.
*
*
* 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,
* 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.
*/
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,
git://wimlib.net / wimlib / blobdiff