Tests: Add .lzma test files.

This commit is contained in:
Lasse Collin 2022-07-14 19:37:42 +03:00
parent 107c93ee5c
commit ce5549a591
9 changed files with 50 additions and 13 deletions

View File

@ -1,31 +1,31 @@
.xz Test Files .xz and .lzma Test Files
---------------- ------------------------
0. Introduction 0. Introduction
This directory contains bunch of files to test handling of .xz files This directory contains bunch of files to test handling of .xz
in .xz decoder implementations. Many of the files have been created and .lzma files in decoder implementations. Many of the files have
by hand with a hex editor, thus there is no better "source code" than been created by hand with a hex editor, thus there is no better
the files themselves. All the test files (*.xz) and this README have "source code" than the files themselves. All the test files and
been put into the public domain. this README have been put into the public domain.
1. File Types 1. File Types
Good files (good-*.xz) must decode successfully without requiring Good files (good-*.xz, good-*.lzma) must decode successfully
a lot of CPU time or RAM. without requiring a lot of CPU time or RAM.
Unsupported files (unsupported-*.xz) are good files, but headers Unsupported files (unsupported-*.xz) are good files, but headers
indicate features not supported by the current file format indicate features not supported by the current file format
specification. specification.
Bad files (bad-*.xz) must cause the decoder to give an error. Like Bad files (bad-*.xz, bad-*.lzma) must cause the decoder to give
with the good files, these files must not require a lot of CPU time an error. Like with the good files, these files must not require
or RAM before they get detected to be broken. a lot of CPU time or RAM before they get detected to be broken.
2. Descriptions of Individual Files 2. Descriptions of Individual .xz Files
2.1. Good Files 2.1. Good Files
@ -266,3 +266,40 @@
Uncompressed Size bytes of output will have been produced but Uncompressed Size bytes of output will have been produced but
the LZMA2 decoder doesn't indicate end of stream. the LZMA2 decoder doesn't indicate end of stream.
3. Descriptions of Individual .lzma Files
3.1. Good Files
good-unknown_size-with_eopm.lzma has unknown size in the header
and end of payload marker at the end.
good-known_size-without_eopm.lzma has a known size in the header
and no end of payload marker at the end.
good-known_size-with_eopm.lzma has a known size in the header
and end of payload marker at the end. XZ Utils 5.2.5 and older
will give an error at the end of the file after producing the
correct uncompressed output.
3.2. Bad Files
bad-unknown_size-without_eopm.lzma has unknown size in the header
but no end of payload marker at the end. This file might be seen
by a decoder as if it were truncated.
bad-too_big_size-with_eopm.lzma has too big uncompressed size in
the header and the end of payload marker will be detected before
the specified number of bytes have been decoded.
bad-too_small_size-without_eopm-1.lzma has too small uncompressed
size in the header. The decoder will look for end of payload marker
but instead find a literal that would produce more output.
bad-too_small_size-without_eopm-2.lzma is like -1 above but instead
of a literal the problem occurs with a short repeated match.
bad-too_small_size-without_eopm-3.lzma is like -1 above but instead
of a literal the problem occurs in the middle of a match.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.