Fixed wrong spelling "limitter" to "limiter". This affects

liblzma's API.

1 files changed, 7 insertions, 7 deletions

diff --git a/doc/liblzma-security.txt b/doc/liblzma-security.txt
index 487637ed..78947bd8 100644
--- a/doc/liblzma-security.txt
+++ b/doc/liblzma-security.txt
@@ -87,7 +87,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
-    memory limitter functions found from <lzma/memlimit.h>.
+    memory limiter functions found from <lzma/memlimit.h>.
 
 
 1.2.1. Encoder
@@ -118,24 +118,24 @@ Using liblzma securely
 
 1.2.2. Decoder
 
-    A single-threaded decoder should simply use a memory limitter and
+    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
     solution is to divide the maximum allowed memory usage with the
     maximum allowed threads, and give each Block decoder their own
-    independent lzma_memory_limitter. The drawback is that if one Block
+    independent lzma_memory_limiter. The drawback is that if one Block
     needs notably more RAM than any other Block, the decoder will run out
     of memory when in reality there would be plenty of free RAM.
 
-    An attractive alternative would be using shared lzma_memory_limitter.
+    An attractive alternative would be using shared lzma_memory_limiter.
     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.
       - x(i) is the decoder memory requirements of the Block number i
         in an expected input Stream.
-      - The memory limitter is set to higher value than the sum of n
+      - The memory limiter is set to higher value than the sum of n
         highest values x(i).
 
     (If you are better at explaining the above conditions, please
@@ -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_limitter for each thread" solution, possibly fallbacking
+    lzma_memory_limiter for each thread" solution, possibly fallbacking
     to single-threaded mode in case the per-thread memory limits aren't
     enough in multi-threaded mode.
 
@@ -206,7 +206,7 @@ FIXME: Memory usage of Stream info.
     creating a denial of service like piping decoded a Data Block to
     another process would do.
 
-    At first it would seem that using a memory limitter would prevent
+    At first it would seem that using a memory limiter would prevent
     this issue as a side effect. But it does so only if the application
     requests liblzma to allocate the Extra Records and provide them to
     the application. If Extra Records aren't requested, they aren't