Fix typos discovered by codespell (#100)

* Fix typos discovered by codespell

* Add a space

Author: cclauss

doc/misc/design.rst

@@ -8,7 +8,7 @@ Design decisions
   of automatic conversions: the various C integer types are
   automatically wrapped and unwrapped to regular applevel integers.  The
   type ``char`` might correspond to single-character strings instead;
-  for integer correspondance you would use ``signed char`` or ``unsigned
+  for integer correspondence you would use ``signed char`` or ``unsigned
   char``.  We might also decide that ``const char *`` automatically maps
   to strings; for cases where you don't want that, use ``char *``.
 

doc/source/cdef.rst

@@ -882,7 +882,7 @@ Extra arguments to ``ffi.verify()``:
      ext = ffi.verify(..., sources=['/path/to/this/file/foo.c'])
 
    except that the default name of the produced library is built from
-   the CRC checkum of the argument ``sources``, as well as most other
+   the CRC checksum of the argument ``sources``, as well as most other
    arguments you give to ``ffi.verify()`` -- but not ``relative_to``.
    So if you used the second line, it would stop finding the
    already-compiled library after your project is installed, because

doc/source/overview.rst

@@ -53,7 +53,7 @@ Create the file ``piapprox_build.py``:
 
       # set_source() gives the name of the python extension module to
       # produce, and some C source code as a string.  This C code needs
-      # to make the declarated functions, types and globals available,
+      # to make the declared functions, types and globals available,
       # so it is often just the "#include".
       ffibuilder.set_source("_pi_cffi",
       """

doc/source/ref.rst

@@ -799,7 +799,7 @@ allowed.
 |  ``double``   | which float() works    |                  | bool(), ``<``  |
 +---------------+------------------------+------------------+----------------+
 |``long double``| another <cdata> with   | a <cdata>, to    | float(), int(),|
-|               | a ``long double``, or  | avoid loosing    | bool()         |
+|               | a ``long double``, or  | avoid losing     | bool()         |
 |               | anything on which      | precision `[3]`  |                |
 |               | float() works          |                  |                |
 +---------------+------------------------+------------------+----------------+
@@ -900,7 +900,7 @@ allowed.
 `[3]` ``long double`` support:
 
    We keep ``long double`` values inside a cdata object to avoid
-   loosing precision.  Normal Python floating-point numbers only
+   losing precision.  Normal Python floating-point numbers only
    contain enough precision for a ``double``.  If you really want to
    convert such an object to a regular Python float (i.e. a C
    ``double``), call ``float()``.  If you need to do arithmetic on
@@ -1011,7 +1011,7 @@ explicitly make using fdopen(), like this:
 
 The special support for ``FILE *`` is anyway implemented in a similar manner
 on CPython 3.x and on PyPy, because these Python implementations' files are
-not natively based on ``FILE *``.  Doing it explicity offers more control.
+not natively based on ``FILE *``.  Doing it explicitly offers more control.
 
 
 .. _unichar:

src/c/_cffi_backend.c

@@ -822,7 +822,7 @@ _my_PyLong_AsLongLong(PyObject *ob)
 {
     /* (possibly) convert and cast a Python object to a long long.
        Like PyLong_AsLongLong(), this version accepts a Python int too, and
-       does convertions from other types of objects.  The difference is that
+       does conversions from other types of objects.  The difference is that
        this version refuses floats. */
 #if PY_MAJOR_VERSION < 3
     if (PyInt_Check(ob)) {
@@ -864,7 +864,7 @@ _my_PyLong_AsUnsignedLongLong(PyObject *ob, int strict)
 {
     /* (possibly) convert and cast a Python object to an unsigned long long.
        Like PyLong_AsLongLong(), this version accepts a Python int too, and
-       does convertions from other types of objects.  If 'strict', complains
+       does conversions from other types of objects.  If 'strict', complains
        with OverflowError and refuses floats.  If '!strict', rounds floats
        and masks the result. */
 #if PY_MAJOR_VERSION < 3
@@ -1105,7 +1105,7 @@ convert_to_object(char *data, CTypeDescrObject *ct)
         else if (ct->ct_flags & CT_ARRAY) {
             if (ct->ct_length < 0) {
                 /* we can't return a <cdata 'int[]'> here, because we don't
-                   know the length to give it.  As a compromize, returns
+                   know the length to give it.  As a compromise, returns
                    <cdata 'int *'> in this case. */
                 ct = (CTypeDescrObject *)ct->ct_stuff;
             }

src/c/libffi_arm64/include/ffi.h

@@ -378,7 +378,7 @@ typedef struct {
 
   /* If this is enabled, then a raw closure has the same layout
      as a regular closure.  We use this to install an intermediate
-     handler to do the transaltion, void** -> ffi_raw*.  */
+     handler to do the translation, void** -> ffi_raw*.  */
 
   void     (*translate_args)(ffi_cif*,void*,void**,void*);
   void      *this_closure;

src/c/libffi_x86_x64/ffi.h

@@ -39,7 +39,7 @@
    e.g. for use by gij.  Routines are provided to emulate the raw API
    if the underlying platform doesn't allow faster implementation.
 
-   More details on the raw and cloure API can be found in:
+   More details on the raw and closure API can be found in:
 
    http://gcc.gnu.org/ml/java/1999-q3/msg00138.html
 
@@ -243,7 +243,7 @@ typedef struct {
 
   /* if this is enabled, then a raw closure has the same layout 
      as a regular closure.  We use this to install an intermediate 
-     handler to do the transaltion, void** -> ffi_raw*. */
+     handler to do the translation, void** -> ffi_raw*. */
 
   void     (*translate_args)(ffi_cif*,void*,void**,void*);
   void      *this_closure;

src/c/libffi_x86_x64/win32.c

@@ -90,7 +90,7 @@ ffi_call_x86(void (* prepfunc)(char *, extended_cif *), /* 8 */
 
 // If the return value pointer is NULL, assume no return value.
 /*
-  Intel asm is weird. We have to explicitely specify 'DWORD PTR' in the nexr instruction,
+  Intel asm is weird. We have to explicitly specify 'DWORD PTR' in the nexr instruction,
   otherwise only one BYTE will be compared (instead of a DWORD)!
  */
 		cmp DWORD PTR [ebp + 24], 0

src/c/minibuffer.h

@@ -1,6 +1,6 @@
 
 /* Implementation of a C object with the 'buffer' or 'memoryview'
- * interface at C-level (as approriate for the version of Python we're
+ * interface at C-level (as appropriate for the version of Python we're
  * compiling for), but only a minimal but *consistent* part of the
  * 'buffer' interface at application level.
  */

src/cffi/cparser.py

@@ -59,7 +59,7 @@ def _workaround_for_old_pycparser(csource):
     # for "char***(*const)".  This means we can't tell the difference
     # afterwards.  But "char(*const(***))" gives us the right syntax
     # tree.  The issue only occurs if there are several stars in
-    # sequence with no parenthesis inbetween, just possibly qualifiers.
+    # sequence with no parenthesis in between, just possibly qualifiers.
     # Attempt to fix it by adding some parentheses in the source: each
     # time we see "* const" or "* const *", we add an opening
     # parenthesis before each star---the hard part is figuring out where

testing/cffi1/test_new_ffi_1.py

@@ -1826,5 +1826,5 @@ def test_char32_t(self):
         assert list(y) == [u+'\u1234', u+'\u5678', u+'\x00']
         z = ffi.new("char32_t[]", u+'\U00012345')
         assert len(z) == 2
-        assert list(z) == [u+'\U00012345', u+'\x00'] # maybe a 2-unichars strin
+        assert list(z) == [u+'\U00012345', u+'\x00'] # maybe a 2-unichars string
         assert ffi.string(z) == u+'\U00012345'