Fix minor typos

lib/brg/aescrypt.c

@@ -51,7 +51,7 @@ extern "C"
 #if ( FUNCS_IN_C & ENCRYPTION_IN_C )
 
 /* Visual C++ .Net v7.1 provides the fastest encryption code when using
-   Pentium optimiation with small code but this is poor for decryption
+   Pentium optimisation with small code but this is poor for decryption
    so we need to control this with the following VC++ pragmas
 */
 
@@ -168,7 +168,7 @@ AES_RETURN aes_xi(encrypt)(const unsigned char *in, unsigned char *out, const ae
 #if ( FUNCS_IN_C & DECRYPTION_IN_C)
 
 /* Visual C++ .Net v7.1 provides the fastest encryption code when using
-   Pentium optimiation with small code but this is poor for decryption
+   Pentium optimisation with small code but this is poor for decryption
    so we need to control this with the following VC++ pragmas
 */
 
@@ -212,7 +212,7 @@ AES_RETURN aes_xi(encrypt)(const unsigned char *in, unsigned char *out, const ae
 #endif
 
 /* This code can work with the decryption key schedule in the   */
-/* order that is used for encrytpion (where the 1st decryption  */
+/* order that is used for encryption (where the 1st decryption  */
 /* round key is at the high end ot the schedule) or with a key  */
 /* schedule that has been reversed to put the 1st decryption    */
 /* round key at the low end of the schedule in memory (when     */

lib/brg/aesopt.h

@@ -64,7 +64,7 @@ Issue Date: 20/12/2007
 
      Class AESencrypt  for encryption
 
-      Construtors:
+      Constructors:
           AESencrypt(void)
           AESencrypt(const unsigned char *key) - 128 bit key
       Members:
@@ -74,7 +74,7 @@ Issue Date: 20/12/2007
           AES_RETURN encrypt(const unsigned char *in, unsigned char *out) const
 
       Class AESdecrypt  for encryption
-      Construtors:
+      Constructors:
           AESdecrypt(void)
           AESdecrypt(const unsigned char *key) - 128 bit key
       Members:
@@ -180,9 +180,9 @@ Issue Date: 20/12/2007
     if it is detected (both present and enabled).
 
 	AESNI uses a decryption key schedule with the first decryption
-	round key at the high end of the key scedule with the following
+	round key at the high end of the key schedule with the following
 	round keys at lower positions in memory.  So AES_REV_DKS must NOT
-	be defined when AESNI will be used.  ALthough it is unlikely that
+	be defined when AESNI will be used.  Although it is unlikely that
 	assembler code will be used with an AESNI build, if it is then
 	AES_REV_DKS must NOT be defined when the assembler files are
 	built
@@ -279,7 +279,7 @@ Issue Date: 20/12/2007
 
 /*  5. LOOP UNROLLING
 
-    The code for encryption and decrytpion cycles through a number of rounds
+    The code for encryption and decryption cycles through a number of rounds
     that can be implemented either in a loop or by expanding the code into a
     long sequence of instructions, the latter producing a larger program but
     one that will often be much faster. The latter is called loop unrolling.
@@ -324,9 +324,9 @@ Issue Date: 20/12/2007
 /*  7. INTERNAL STATE VARIABLE FORMAT
 
     The internal state of Rijndael is stored in a number of local 32-bit
-    word varaibles which can be defined either as an array or as individual
+    word variables which can be defined either as an array or as individual
     names variables. Include this section if you want to store these local
-    varaibles in arrays. Otherwise individual local variables will be used.
+    variables in arrays. Otherwise individual local variables will be used.
 */
 #if 1
 #  define ARRAYS
@@ -355,10 +355,10 @@ Issue Date: 20/12/2007
 
 /*  10. TABLE ALIGNMENT
 
-    On some sytsems speed will be improved by aligning the AES large lookup
+    On some systems speed will be improved by aligning the AES large lookup
     tables on particular boundaries. This define should be set to a power of
     two giving the desired alignment. It can be left undefined if alignment
-    is not needed.  This option is specific to the Microsft VC++ compiler -
+    is not needed.  This option is specific to the Microsoft VC++ compiler -
     it seems to sometimes cause trouble for the VC++ version 6 compiler.
 */
 
@@ -383,7 +383,7 @@ Issue Date: 20/12/2007
     up using tables.  The basic tables are each 256 32-bit words, with either
     one or four tables being required for each round function depending on
     how much speed is required. The encryption and decryption round functions
-    are different and the last encryption and decrytpion round functions are
+    are different and the last encryption and decryption round functions are
     different again making four different round functions in all.
 
     This means that:
@@ -482,7 +482,7 @@ Issue Date: 20/12/2007
    a column number c to the way the state array variable is to be held.
    The first define below maps the state into an array x[c] whereas the
    second form maps the state into a number of individual variables x0,
-   x1, etc.  Another form could map individual state colums to machine
+   x1, etc.  Another form could map individual state columns to machine
    register names.
 */
 

lib/brg/brg_types.h

@@ -175,7 +175,7 @@ extern "C" {
                                 length 'size' bits
 
     UPTR_CAST(x,size)           casts a pointer to a pointer to a 
-                                varaiable of length 'size' bits
+                                variable of length 'size' bits
 */
 
 #define UI_TYPE(size)               uint##size##_t

lib/brg/sha2.c

@@ -385,7 +385,7 @@ static void sha_end1(unsigned char hval[], sha256_ctx ctx[1], const unsigned int
     sha256_compile(ctx);
 
     /* extract the hash value as bytes in case the hash buffer is   */
-    /* mislaigned for 32-bit words                                  */
+    /* misaligned for 32-bit words                                  */
     for(i = 0; i < hlen; ++i)
         hval[i] = ((ctx->hash[i >> 2] >> (8 * (~i & 3))) & 0xff);
 }

lib/bzip2/bzlib.c

@@ -70,7 +70,7 @@ void BZ2_bz__AssertH__fail ( int errcode )
       "  points in compression, you may have a flaky memory system.\n"
       "  Try a memory-test program.  I have used Memtest86\n"
       "  (www.memtest86.com).  At the time of writing it is free (GPLd).\n"
-      "  Memtest86 tests memory much more thorougly than your BIOSs\n"
+      "  Memtest86 tests memory much more thoroughly than your BIOSs\n"
       "  power-on test, and may find failures that the BIOS doesn't.\n"
       "\n"
       "* If the error can be repeatably reproduced, this is a bug in\n"

lib/bzip2/bzlib.h

@@ -71,7 +71,7 @@ typedef
 #endif
 
 #ifndef BZ_NO_STDIO
-/* Need a definitition for FILE */
+/* Need a definition for FILE */
 #include <stdio.h>
 #endif
 

lib/liblzma/api/lzma/base.h

@@ -447,7 +447,7 @@ typedef struct lzma_internal_s lzma_internal;
  *
  * The lzma_stream structure is used for
  *  - passing pointers to input and output buffers to liblzma;
- *  - defining custom memory hander functions; and
+ *  - defining custom memory handler functions; and
  *  - holding a pointer to coder-specific internal data structures.
  *
  * Typical usage:

lib/liblzma/api/lzma/lzma12.h

@@ -301,7 +301,7 @@ typedef struct {
 	 * (2^ pb =2^2=4), which is often a good choice when there's
 	 * no better guess.
 	 *
-	 * When the aligment is known, setting pb accordingly may reduce
+	 * When the alignment is known, setting pb accordingly may reduce
 	 * the file size a little. E.g. with text files having one-byte
 	 * alignment (US-ASCII, ISO-8859-*, UTF-8), setting pb=0 can
 	 * improve compression slightly. For UTF-16 text, pb=1 is a good

lib/liblzma/api/lzma/vli.h

@@ -54,7 +54,7 @@
  *
  * Valid VLI values are in the range [0, LZMA_VLI_MAX]. Unknown value is
  * indicated with LZMA_VLI_UNKNOWN, which is the maximum value of the
- * underlaying integer type.
+ * underlying integer type.
  *
  * lzma_vli will be uint64_t for the foreseeable future. If a bigger size
  * is needed in the future, it is guaranteed that 2 * LZMA_VLI_MAX will

lib/liblzma/lz/lz_decoder.c

@@ -241,7 +241,7 @@ lzma_lz_decoder_init(lzma_next_coder *next, const lzma_allocator *allocator,
 	if (lz_options.dict_size < 4096)
 		lz_options.dict_size = 4096;
 
-	// Make dictionary size a multipe of 16. Some LZ-based decoders like
+	// Make dictionary size a multiple of 16. Some LZ-based decoders like
 	// LZMA use the lowest bits lzma_dict.pos to know the alignment of the
 	// data. Aligned buffer is also good when memcpying from the
 	// dictionary to the output buffer, since applications are