Bunch of grammar fixes from meyering.

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.
 

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().

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'
 ));

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