aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/liblzma-security.txt8
-rw-r--r--src/liblzma/api/lzma/memlimit.h6
-rw-r--r--src/lzma/help.c2
-rw-r--r--tests/files/README2
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