7 Memory limits in the command line tool apply only to compression.
9 Threading support in the lzma command line tool is still primitive.
10 It cannot split a file in pieces yet.
12 The --list mode isn't implemented in the command line tool.
14 Handling of Multi-Block Stream information should be separated
15 from Stream encoder and decoder. Those would be useful to implement
16 multi-threaded coding in applications.
18 Buffer to buffer coding is not implemented in liblzma. Probably
19 a naive version should be written first, which would simply wrap
20 things around lzma_stream. Later, there should be separate buffer
21 coding functions, that are slightly faster (less memcpy()) and
22 have smaller memory usage than the functions using lzma_stream.
24 libzfile is not implemented.
26 LZMA filter doesn't support predefined history buffer.
31 Search for bugs, especially security related issues. Security is
32 important in every piece of code in LZMA Utils, but it is extremely
33 important in the decoder part of liblzma.
35 Subblock: If there is LZMA as a Subfilter but without EOPM, can it
36 trigger infinite loop when Subblock's "Unset Subfilter" flag is hit?
38 Similarly, can LZ decoder get stuck in infinite loop if the next
39 filter in the chain returns LZMA_STREAM_END but the decoded data
40 doesn't allow finishing the LZ decoding?
45 Create a test suite to be run with "make check".
47 Should we use strlimit() and getrlimit() for memory usage limitting?
52 Benchmark the CRC code on non-x86 CPUs. Won't have huge effect on
53 overall speed, but it would still be nice to know what algorithm
54 variant is the best on different CPUs.
59 Add support for LZMA to various applications. This naturally requires
60 cooperating with the authors of the specific applications.
61 * GNU grep and GNU diffutils: BSD grep already uses zlib directly
62 instead of ugly shell scripts. It would be nice to get similar
63 feature into relevant GNU tools. With libzfile, multiple
64 compression formats would be easy to support.
66 * Magic for the `file' command
67 * GNU Midnight Commander
72 Test the patches already written. The patches should be sent to
73 upstream developers _once_ LZMA Utils APIs are stable enough (so
74 people don't need to fix those patches all the time).
76 Mandriva has quite a few patches. Some of them are OK, some need
77 adapting for new LZMA Utils.
82 Revise the man page of lzma command line tool.
84 If the Doxygen docs aren't enough, write good Texinfo manual for
85 liblzma. It's been a long time I've even tried to build the Doxygen
86 docs, so they may look quite bad at the moment.
88 Document LZMA as an algorithm. It would be great to have detailed
89 description of the algorithm in English. Many people think, that
90 reading the source code is not the optimal way to learn how LZMA
96 Some things return LZMA_PROG_ERROR with invalid options, some
97 LZMA_HEADER_ERROR. These must be checked carefully and made so
98 that LZMA_HEADER_ERROR is used only when the given option could
99 make sense in future version of libzma.
101 lzma_restrict vs. restrict
103 Usage of LZMA_RUN vs. LZMA_FINISH with Metadata coders.
105 Port the Deflate implementation from 7-Zip into liblzma. 7-Zip's
106 Deflate compresses better than zlib, gzip or Info-ZIP. I don't
107 know if Deflate will be included in .lzma format (probably not),
108 but it's still useful once we also add support for .gz file format.