diff options
| -rw-r--r-- | doc/liblzma-security.txt | 8 | ||||
| -rw-r--r-- | src/liblzma/api/lzma/memlimit.h | 6 | ||||
| -rw-r--r-- | src/lzma/help.c | 2 | ||||
| -rw-r--r-- | tests/files/README | 2 |
4 files changed, 9 insertions, 9 deletions
diff --git a/doc/liblzma-security.txt b/doc/liblzma-security.txt index 78947bd8..55bc57bc 100644 --- a/doc/liblzma-security.txt +++ b/doc/liblzma-security.txt @@ -86,7 +86,7 @@ Using liblzma securely The simplest solution is to use setrlimit() if the kernel supports RLIMIT_AS, which limits the memory usage of the whole process. - For more portable and fine-grained limitting, you can use + For more portable and fine-grained limiting, you can use memory limiter functions found from <lzma/memlimit.h>. @@ -121,7 +121,7 @@ Using liblzma securely A single-threaded decoder should simply use a memory limiter and indicate an error if it runs out of memory. - Memory-limitting with multi-threaded decoding is tricky. The simple + Memory-limiting with multi-threaded decoding is tricky. The simple solution is to divide the maximum allowed memory usage with the maximum allowed threads, and give each Block decoder their own independent lzma_memory_limiter. The drawback is that if one Block @@ -132,7 +132,7 @@ Using liblzma securely Depending on the application and the expected type of input, this may either be the best solution or a source of hard-to-repeat problems. Consider the following requirements: - - You use at maximum of n threads. + - You use a maximum of n threads. - x(i) is the decoder memory requirements of the Block number i in an expected input Stream. - The memory limiter is set to higher value than the sum of n @@ -150,7 +150,7 @@ Using liblzma securely Most .lzma files have all the Blocks encoded with identical settings, or at least the memory usage won't vary dramatically. That's why most multi-threaded decoders probably want to use the simple "separate - lzma_memory_limiter for each thread" solution, possibly fallbacking + lzma_memory_limiter for each thread" solution, possibly falling back to single-threaded mode in case the per-thread memory limits aren't enough in multi-threaded mode. diff --git a/src/liblzma/api/lzma/memlimit.h b/src/liblzma/api/lzma/memlimit.h index 6b07679d..7a856a27 100644 --- a/src/liblzma/api/lzma/memlimit.h +++ b/src/liblzma/api/lzma/memlimit.h @@ -22,7 +22,7 @@ /** - * \brief Opaque data type used with the memory usage limitting functions + * \brief Opaque data type used with the memory usage limiting functions */ typedef struct lzma_memlimit_s lzma_memlimit; @@ -39,7 +39,7 @@ typedef struct lzma_memlimit_s lzma_memlimit; * to these functions can be used in lzma_allocator structure, which makes * it easy to limit memory usage with liblzma. * - * The memory limiter functions are not tied to limitting memory usage + * The memory limiter functions are not tied to limiting memory usage * with liblzma itself. You can use them with anything you like. * * In multi-threaded applications, only one thread at once may use the same @@ -161,7 +161,7 @@ extern void *lzma_memlimit_alloc( /** - * \brief Removes the pointer from memory limitting list + * \brief Removes the pointer from memory limiting list * * \param mem Pointer to a lzma_memlimit structure returned * earlier by lzma_memry_limit_create(). diff --git a/src/lzma/help.c b/src/lzma/help.c index 85d754ec..7f8be669 100644 --- a/src/lzma/help.c +++ b/src/lzma/help.c @@ -124,7 +124,7 @@ These aren't implemented yet. " Resource usage options:\n" "\n" " -M, --memory=NUM use roughly NUM bytes of memory at maximum\n" -" -T, --threads=NUM use at maximum of NUM (de)compression threads\n" +" -T, --threads=NUM use a maximum of NUM (de)compression threads\n" // " --threading=STR threading style; possible values are `auto' (default),\n" // " `files', and `stream' )); diff --git a/tests/files/README b/tests/files/README index 4a7d5f88..4d0ef8bd 100644 --- a/tests/files/README +++ b/tests/files/README @@ -25,7 +25,7 @@ specification, but try to trigger excessive CPU, RAM or disk usage in the decoder. To prevent malicious files from putting the decoder in inifinite loop (*), eating all available RAM or disk space, decoders - should have internal limitters that catch these situations. + should have internal limiters that catch these situations. (*) Strictly speaking not infinite, but if decoding of a small file would take a few weeks or even years, it's an infinite loop in |