Fix some spelling and grammar (#27)

* Fix some spelling errors

* Fix some spelling errors

* Fix some spelling errors

* Fix some spelling errors

* Fix some spelling errors

Author: jc21

Book/php7/extensions_design/extension_infos.rst

@@ -87,7 +87,7 @@ macro resolves to `display_ini_entries()
 A note about the Reflection API
 -------------------------------
 
-The Reflection heavilly uses your ``zend_module_entry`` structure. For example, when you call 
+The Reflection heavily uses your ``zend_module_entry`` structure. For example, when you call 
 ``ReflectionExtension::getVersion()``, the API just reads the version field of your ``zend_module_entry`` structure.
 
 Same to discover functions, your ``zend_module_entry`` has got a ``const struct _zend_function_entry *functions`` member 

Book/php7/extensions_design/extension_skeleton.rst

@@ -1,32 +1,32 @@
 PHP's custom printf functions
 =============================
 
-You all know libc's ``printf()`` and family. This chapter will detail those many clones PHP declares and use, what's 
+You all know libc's ``printf()`` and family. This chapter will detail those many clones PHP declares and use, what's
 their goal, why use them and when to use them.
 
-.. note:: Libc's documentation about ``printf()`` and friends 
+.. note:: Libc's documentation about ``printf()`` and friends
           `is located here <https://www.gnu.org/software/libc/manual/html_node/Formatted-Output-Functions.html>`_
-          
+
 You know that those functions are useful, but sometimes don't provide enough functionalities.
-Also, you know that 
-`adding format strings <https://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html>`_ to ``printf()`` 
+Also, you know that
+`adding format strings <https://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html>`_ to ``printf()``
 family is not trivial, not portable and security risky.
 
 PHP adds its own printf-like functions to replace libc ones and to be used by the internal developer.
-They will mainly add new formats, play with :doc:`zend_string<zend_strings>` instead of 
+They will mainly add new formats, play with :doc:`zend_string<zend_strings>` instead of
 ``char *``, etc...  Let's see them together.
 
-.. warning:: You must master your libc default ``printf()`` formats. Read 
+.. warning:: You must master your libc default ``printf()`` formats. Read
              `their documentation here <http://www.cplusplus.com/reference/cstdio/printf/>`_.
-             
-.. note::  Those functions are added **to replace** libc ones, that means that if you use ``sprintf()`` f.e, that won't 
-           lead to libc's ``sprintf()``, but to PHP replacement. Except the traditionnal ``printf()``, everything else 
+
+.. note::  Those functions are added **to replace** libc ones, that means that if you use ``sprintf()`` f.e, that won't
+           lead to libc's ``sprintf()``, but to PHP replacement. Except the traditional ``printf()``, everything else
            is replaced.
 
-Traditionnal use
-****************
+Traditional use
+***************
 
-First of all, you should not use ``sprintf()``, as that function doesn't perform any check and allows many buffer 
+First of all, you should not use ``sprintf()``, as that function doesn't perform any check and allows many buffer
 overflow errors. Please, try to avoid using it.
 
 .. warning:: Please try to avoid using ``sprintf()`` as much as possible.
@@ -36,12 +36,12 @@ Then, you have some choice.
 You know your result buffer size
 --------------------------------
 
-If you know your buffer size, ``snprintf()`` or ``slprintf()`` will do the job for you. There is a difference in what 
+If you know your buffer size, ``snprintf()`` or ``slprintf()`` will do the job for you. There is a difference in what
 those functions return, but not in what those functions do.
 
-They both print according to the formats passed, and they both terminate your buffer by a ``NUL`` byte *'\\0'* whatever 
-happens. However, ``snprintf()`` returns the number of characters that could have been used, whereas ``slprintf()`` 
-returns the number of characters that have effectively been used, thus enabling to detect too-small buffers and string 
+They both print according to the formats passed, and they both terminate your buffer by a ``NUL`` byte *'\\0'* whatever
+happens. However, ``snprintf()`` returns the number of characters that could have been used, whereas ``slprintf()``
+returns the number of characters that have effectively been used, thus enabling to detect too-small buffers and string
 truncation. This, is not counting the final *'\\0'*.
 
 Here is an example so that you fully understand::
@@ -52,12 +52,12 @@ Here is an example so that you fully understand::
 
     r = snprintf(foo, sizeof(foo), "%s", str);
     /* r = 11 here even if only 7 printable chars were written in foo */
-	
+
     /* foo value is now 'H' 'e' 'l' 'l' 'o' ' ' 'w' '\0' */
 
 ``snprintf()`` is not a good function to use, as it does not allows to detect an eventual string truncation.
-As you can see from the example above, "Hello world\\0" doesn't fit in an eight-byte buffer, that's obvious, but 
-``snprintf()`` still returns you 11, which is ``strlen("Hello world\0")``. You have no way to detect that the string's 
+As you can see from the example above, "Hello world\\0" doesn't fit in an eight-byte buffer, that's obvious, but
+``snprintf()`` still returns you 11, which is ``strlen("Hello world\0")``. You have no way to detect that the string's
 got truncated.
 
 Here is ``slprintf()``::
@@ -68,10 +68,10 @@ Here is ``slprintf()``::
 
     r = slprintf(foo, sizeof(foo), "%s", str);
     /* r = 7 here , because 7 printable chars were written in foo */
-	
+
     /* foo value is now 'H' 'e' 'l' 'l' 'o' ' ' 'w' '\0' */
 
-With ``slprintf()``, the result buffer ``foo`` contains the exact same string, but the returned value is now 7. 7 is 
+With ``slprintf()``, the result buffer ``foo`` contains the exact same string, but the returned value is now 7. 7 is
 less than the 11 chars from the *"Hello world"* string, thus you can detect that it got truncated::
 
     if (slprintf(foo, sizeof(foo), "%s", str) < strlen(str)) {
@@ -83,7 +83,7 @@ Remember:
 * Those two function always ``NUL`` terminate the string, truncation or not. Result strings are then safe C strings.
 * Only ``slprintf()`` allows to detect a string truncation.
 
-Those two functions are defined in 
+Those two functions are defined in
 `main/snprintf.c <https://github.com/php/php-src/blob/648be8600ff89e1b0e4a4ad25cebad42b53bed6d/main/snprintf.c>`_
 
 You don't know your buffer size
@@ -95,106 +95,106 @@ Remember that **you'll have to free** the buffer by yourself !
 Here is an example::
 
     #include <time.h>
-    
+
     char *result;
     int r;
 
     time_t timestamp = time(NULL);
 
     r = spprintf(&result, 0, "Here is the date: %s", asctime(localtime(&timestamp)));
-	
+
     /* now use result that contains something like "Here is the date: Thu Jun 15 19:12:51 2017\n" */
-	
+
     efree(result);
 
-``spprintf()`` returns the number of characters that've been printed into the result buffer, not counting the final 
+``spprintf()`` returns the number of characters that've been printed into the result buffer, not counting the final
 *'\\0'*, hence you know the number of bytes that got allocated for you (minus one).
 
-Please, note that the allocation is done using ZendMM (request allocation), and should thus be used as part of a 
+Please, note that the allocation is done using ZendMM (request allocation), and should thus be used as part of a
 request and freed using ``efree()`` and not ``free()``.
 
-.. note:: :doc:`The chapter about Zend Memory Manager <../../memory_management/zend_memory_manager>` (ZendMM) details 
+.. note:: :doc:`The chapter about Zend Memory Manager <../../memory_management/zend_memory_manager>` (ZendMM) details
           how dynamic memory is allocated through PHP.
 
-If you want to limit the buffer size, you pass that limit as the second argument, if you pass *0*, that means 
+If you want to limit the buffer size, you pass that limit as the second argument, if you pass *0*, that means
 unlimited::
 
     #include <time.h>
-    
+
     char *result;
     int r;
 
     time_t timestamp = time(NULL);
 
     /* Do not print more than 10 bytes || allocate more than 11 bytes */
     r = spprintf(&result, 10, "Here is the date: %s", asctime(localtime(&timestamp)));
-	
+
     /* r == 10 here, and 11 bytes were allocated into result */
-	
+
     efree(result);
 
-.. note:: Whenever possible, try not to use dynamic memory allocations. That impacts performances. If you got the 
+.. note:: Whenever possible, try not to use dynamic memory allocations. That impacts performances. If you got the
           choice, go for the static stack allocated buffer.
 
-``spprintf()`` is written in 
+``spprintf()`` is written in
 `main/spprintf.c <https://github.com/php/php-src/blob/648be8600ff89e1b0e4a4ad25cebad42b53bed6d/main/spprintf.c>`_.
 
 What about printf() ?
 ---------------------
 
-If you need to ``printf()``, aka to print formatted to the output stream, use ``php_printf()``. That function 
-internally uses ``spprintf()``, and thus performs a dynamic allocation that it frees itself just after having sent it 
+If you need to ``printf()``, aka to print formatted to the output stream, use ``php_printf()``. That function
+internally uses ``spprintf()``, and thus performs a dynamic allocation that it frees itself just after having sent it
 to the SAPI output, aka stdout in case of CLI, or the output buffer (CGI buffer f.e) for other SAPIs.
 
 Special PHP printf formats
 --------------------------
 
-Remember that PHP replaces most libc's ``printf()`` functions by its own of its own design. You can have a look at 
-the argument parsing API which is easy to understand `from reading the source 
+Remember that PHP replaces most libc's ``printf()`` functions by its own of its own design. You can have a look at
+the argument parsing API which is easy to understand `from reading the source
 <https://github.com/php/php-src/blob/509f5097ab0b578adc311c720afcea8de266aadd/main/spprintf.c#L203>`_.
 
 What that means is that arguments parsing algo has been fully rewritten, and may differ from what you're used to in libc.
-F.e, the libc locale is note taken care of in most cases.
+F.e, the libc locale is not taken care of in most cases.
 
 Special formats may be used, like *"%I64"* to explicitely print to an int64, or *"%I32"*.
 You can also use *"%Z"* to make a zval printable (according to PHP cast rules to string), that one is a great addition.
 
 The formatter will also recognize infinite numbers and print "INF", or "NAN" for not-a-number.
 
-If you make a mistake, and ask the formatter to print a ``NULL`` pointer, where libc will crash for sure, PHP will 
+If you make a mistake, and ask the formatter to print a ``NULL`` pointer, where libc will crash for sure, PHP will
 return *"(null)"* as a result string.
 
-.. note:: If in a printf you see a magic *"(null)"* appearing, that means you passed a NULL pointer to one of PHP 
+.. note:: If in a printf you see a magic *"(null)"* appearing, that means you passed a NULL pointer to one of PHP
           printf family functions.
 
 
 Printf()ing into zend_strings
 -----------------------------
 
-As :doc:`zend_string <zend_strings>` are a very common structure into PHP source, you may need to ``printf()`` into a 
-``zend_string`` instead of a traditionnal C ``char *``.  For this, use ``strpprintf()``.
+As :doc:`zend_string <zend_strings>` are a very common structure into PHP source, you may need to ``printf()`` into a
+``zend_string`` instead of a traditional C ``char *``.  For this, use ``strpprintf()``.
 
-Tha API is ``zend_string *strpprintf(size_t max_len, const char *format, ...)`` that means that the ``zend_string`` is 
-returned to you, and not the number of printed chars as you may expect. You can limit that number though, using the 
-first parameter (pass 0 to mean infinite); and you must remember that the ``zend_string`` will be allocated using the 
+The API is ``zend_string *strpprintf(size_t max_len, const char *format, ...)`` that means that the ``zend_string`` is
+returned to you, and not the number of printed chars as you may expect. You can limit that number though, using the
+first parameter (pass 0 to mean infinite); and you must remember that the ``zend_string`` will be allocated using the
 Zend Memory Manager, and thus bound to the current request.
 
 Obviously, the format API is shared with the one seen above.
 
 Here is a quick example::
 
     zend_string *result;
-    
+
     result = strpprintf(0, "You are using PHP %s", PHP_VERSION);
-    
+
     /* Do something with result */
-    
+
     zend_string_release(result);
 
 A note on ``zend_`` API
 -----------------------
 
 You may meet ``zend_spprintf()``, or ``zend_strpprintf()`` functions. Those are the exact same as the ones seen above.
 
-They are just here as part of the separation between the Zend Engine and PHP Core, a detail that is not important for 
+They are just here as part of the separation between the Zend Engine and PHP Core, a detail that is not important for
 us, as into the source code, everything gets mixed together.

Book/php7/extensions_design/zend_extensions.rst

@@ -1,14 +1,14 @@
 smart_str API
 =============
 
-That may seem strange, but the C language offers nearly nothing to play with strings (build, concatenate, shrink, 
-expand, transform, etc...). C is a low level general purpose language one can use to build APIs to deal with more 
+That may seem strange, but the C language offers nearly nothing to play with strings (build, concatenate, shrink,
+expand, transform, etc...). C is a low level general purpose language one can use to build APIs to deal with more
 specific tasks, such as string constructions.
 
 .. note:: Obviously you all got that we talk about ASCII strings, aka bytes. No Unicode in there.
 
 PHP's ``smart_str`` is an API that will help you build strings and especially concatenate chunks of bytes into strings.
-This API seats next to :doc:`PHP's special printf() APIs<printing_functions>` and :doc:`zend_string <zend_strings>` to 
+This API seats next to :doc:`PHP's special printf() APIs<printing_functions>` and :doc:`zend_string <zend_strings>` to
 help with strings management.
 
 smart_str VS smart_string
@@ -26,29 +26,29 @@ Here are the two structures::
         zend_string *s;
         size_t a;
     } smart_str;
-    
-Like you can see, one will work with traditionnal C strings (as ``char*/size_t``) and the other will make use of the 
+
+Like you can see, one will work with traditional C strings (as ``char*/size_t``) and the other will make use of the
 PHP's specific ``zend_string`` structure.
 
-We will detail the later: ``smart_str``, that works with :doc:`zend_strings`. Both APIs are exactly the same, simply 
-note that one (the one we'll detail here) starts by ``smart_str_**()`` and the other by ``smart_string_***()``. Don't 
+We will detail the latter: ``smart_str``, that works with :doc:`zend_strings`. Both APIs are exactly the same, simply
+note that one (the one we'll detail here) starts by ``smart_str_**()`` and the other by ``smart_string_***()``. Don't
 confuse !
 
-The ``smart_str`` API is detailed into `Zend/zend_smart_str.h 
-<https://github.com/php/php-src/blob/509f5097ab0b578adc311c720afcea8de266aadd/Zend/zend_smart_str.h>`_ (also the .c 
+The ``smart_str`` API is detailed into `Zend/zend_smart_str.h
+<https://github.com/php/php-src/blob/509f5097ab0b578adc311c720afcea8de266aadd/Zend/zend_smart_str.h>`_ (also the .c
 file).
 
 .. warning:: ``smart_str`` is not to be confused with ``smart_string``.
 
 Basic API usage
 ***************
 
-So far so good, that API is really easy to manage. You basically stack-allocate a ``smart_str``, and pass its pointer to 
-``smart_str_***()`` API functions that manage the embedded ``zend_string`` for you. You build your string, use it, and 
+So far so good, that API is really easy to manage. You basically stack-allocate a ``smart_str``, and pass its pointer to
+``smart_str_***()`` API functions that manage the embedded ``zend_string`` for you. You build your string, use it, and
 then you free it. Nothing very strong in there right ?
 
-The embedded ``zend_string`` will be allocated whether 
-:doc:`permanently or request-bound <../../memory_management/zend_memory_manager>`, that depends on the last extended API 
+The embedded ``zend_string`` will be allocated whether
+:doc:`permanently or request-bound <../../memory_management/zend_memory_manager>`, that depends on the last extended API
 parameter you'll use::
 
     smart_str my_str = {0};
@@ -66,36 +66,36 @@ parameter you'll use::
 
     /* Use my_str now */
     PHPWRITE(ZSTR_VAL(my_str.s), ZSTR_LEN(my_str.s));
-    
+
     /* Don't forget to release/free it */
     smart_str_free(&my_str);
 
 
-We used here the simple API, the extended one ends with ``_ex()``, and allows you to tell if you want a persistent or 
+We used here the simple API, the extended one ends with ``_ex()``, and allows you to tell if you want a persistent or
 a request-bound allocation for the underlying ``zend_string``. Example::
 
     smart_str my_str = {0};
-    
+
     smart_str_appends_ex(&my_str, "Hello world", 1); /* 1 means persistent allocation */
 
-Then, depending on what you want to append, you'll use the right API call. If you append a classical C string, you can 
-use ``smart_str_appends(smart_str *dst, const char *src)``. If you make use of a binary string, and thus know its 
+Then, depending on what you want to append, you'll use the right API call. If you append a classical C string, you can
+use ``smart_str_appends(smart_str *dst, const char *src)``. If you make use of a binary string, and thus know its
 length, then use ``smart_str_appendl(smart_str *dst, const char *src, size_t len)``.
 
-The less specific ``smart_str_append(smart_str *dest, const zend_string *src)`` simply appends a ``zend_string`` to 
-your ``smart_str`` string. And if you come to play with others ``smart_str``, use 
+The less specific ``smart_str_append(smart_str *dest, const zend_string *src)`` simply appends a ``zend_string`` to
+your ``smart_str`` string. And if you come to play with others ``smart_str``, use
 ``smart_str_append_smart_str(smart_str *dst, const smart_str *src)`` to combine them together.
 
 smart_str specific tricks
 *************************
 
-* Never forget to finish your string with a call to ``smart_str_0()``. That puts a *NUL* char at the end of the embed 
+* Never forget to finish your string with a call to ``smart_str_0()``. That puts a *NUL* char at the end of the embed
   string and make it compatible with libc string functions.
 * Never forget to free your string, with ``smart_str_free()``, once you're done with it.
-* ``smart_str`` embeds a ``zend_string``, and then allows you to share that later elsewhere playing with its reference 
+* ``smart_str`` embeds a ``zend_string``, and then allows you to share that later elsewhere playing with its reference
   counter. Please, visit the :doc:`zend_string dedicated chapter <zend_strings>` to know more about it.
 * You can play with ``smart_str`` allocations. Look at ``smart_str_alloc()`` and friends.
-* ``smart_str`` is heavilly used into PHP's heart. For example, PHP's 
-  :doc:`specific printf() functions <printing_functions>` internally use a ``smart_str`` buffer. 
+* ``smart_str`` is heavily used into PHP's heart. For example, PHP's
+  :doc:`specific printf() functions <printing_functions>` internally use a ``smart_str`` buffer.
 * ``smart_str`` is definitely an easy structure you need to master.