liblzma: Add optional autodetection of LZMA end marker.

Turns out that this is needed for .lzma files as the spec in
LZMA SDK says that end marker may be present even if the size
is stored in the header. Such files are rare but exist in the
real world. The code in liblzma is so old that the spec didn't
exist in LZMA SDK back then and I had understood that such
files weren't possible (the lzma tool in LZMA SDK didn't
create such files).

This modifies the internal API so that LZMA decoder can be told
if EOPM is allowed even when the uncompressed size is known.
It's allowed with .lzma and not with other uses.

Thanks to Karl Beldan for reporting the problem.

1 files changed, 9 insertions, 2 deletions

diff --git a/doc/lzma-file-format.txt b/doc/lzma-file-format.txt
index 015b0fae..4865defd 100644
--- a/doc/lzma-file-format.txt
+++ b/doc/lzma-file-format.txt
@@ -40,7 +40,11 @@ The .lzma File Format
 
 0.2. Changes
 
-        Last modified: 2011-04-12 11:55+0300
+        Last modified: 2022-07-13 21:00+0300
+
+        Compared to the previous version (2011-04-12 11:55+0300)
+        the section 1.1.3 was modified to allow End of Payload Marker
+        with a known Uncompressed Size.
 
 
 1. File Format
@@ -129,7 +133,10 @@ The .lzma File Format
         Uncompressed Size is stored as unsigned 64-bit little endian
         integer. A special value of 0xFFFF_FFFF_FFFF_FFFF indicates
         that Uncompressed Size is unknown. End of Payload Marker (*)
-        is used if and only if Uncompressed Size is unknown.
+        is used if Uncompressed Size is unknown. End of Payload Marker
+        is allowed but rarely used if Uncompressed Size is known.
+        XZ Utils 5.2.5 and older don't support .lzma files that have
+        End of Payload Marker together with a known Uncompressed Size.
 
         XZ Utils rejects files whose Uncompressed Size field specifies
         a known size that is 256 GiB or more. This is to reject false