Hello Assaf,
Assaf Gordon wrote:
I do have some concerns about the lzip program:
It is written in C++. Not a problem by itself, but seems a bit at odds as a
requirement for system-level package like coreutils.
I maintain 3 lzip (de)compressors written in C:
http://www.nongnu.org/lzip/clzip.html
http://www.nongnu.org/lzip/lunzip.html
http://www.nongnu.org/lzip/pdlzip.html
But there are more, including a version of 7-Zip with lzip decompression
support built in:
http://github.com/mcmilk/7-Zip-zstd
I'm not sure how portable and well-tested the program is on the large number of
platforms that coreutils aim to cater to.
Lzip itself is pretty portable. The C versions are even more portable
(clzip has been compiled wit gcc 2.7.2 IIRC). Lunzip provides a "low
memory" mode able to decompress any file using as little memory as 50
kB, irrespective of the dictionary size used to compress the file. It
has been tested on a laptop with a 486 processor and 4 MiB of RAM.
About how well-tested lzip is, you can see
http://www.nongnu.org/lzip/manual/lzip_manual.html#Quality-assurance
I think the test suite is a bit lacking, especially compared to all the claims
about recovery and robustness of the lzip format.
The test suite run by 'make check' is just a minuscule subset of the
full tests. As you can read in the link above:
"Three related but independent compressor implementations, lzip, clzip
and minilzip/lzlib, are developed concurrently. Every stable release of
any of them is subjected to a hundred hours of intensive testing to
verify that it produces identical output to the other two".
and
"Additionally, the three implementations have been extensively tested
with unzcrash, valgrind and 'american fuzzy lop' without finding a
single vulnerability or false negative".
Best regards,
Antonio.
