Remove some end-of-line whitespace.

mojo/public/c/docs/bindings/TUTORIAL.md

 # C bindings guide
 
 The Mojo C bindings are a way to talk the Mojom protocol, the canonical protocol
 for communication between Mojo programs. The library under `bindings/` provides
 functionality for encoding, decoding and other computation, so it needs to be
 linked together with C code generated from .mojom files. These C bindings are
 lower-level than the C++ bindings (or any other language, for that matter),
 are more error-prone, and require some knowledge of the C Mojo API and the
 mojom encoding format. This document assumes the reader knows about (or knows
 how to look up) this relevant information. Consequently, C bindings can also
@@ skipping 43 matching lines @@
 struct, with some restrictions; in the example above, we see that the order of
 the fields is different between the mojom and C structs, since the generated C
 structs are in packing order, not ordinal order. Although not applicable in this
 example, there may be additional fields inserted in the generated C struct for
 padding purposes -- since 4-byte data types need to be 4-byte aligned, the
 generated C bindings may include some fields not explicitly present in the
 mojom. Since it's not immediately obvious where padding fields could be
 inserted, it helps to examine the generated C struct to make sure what the
 fields are, and if possible, set them using field initializers. The
 `example_PersonPtr` union is used to represent an offset in the encoded form, or
-a pointer in the unencoded form. 
+a pointer in the unencoded form.
 
 Since mojom objects appear in depth-first order relative to their parent object,
 we can use a `struct MojomBuffer` and calls to `MojomBuffer_Allocate(..)` to
 linearly allocate space. The struct needs to be constructed and provided by the
 user, and it contains 3 fields:  A pointer to the buffer, size of the buffer in
-bytes, and the byte-position of the next allocation, typically set to 0. 
+bytes, and the byte-position of the next allocation, typically set to 0.
 
 For instance, to allocate space for the `name` parameter of an `example_Person`,
 we can do so this way:
 ```C
 char byte_buffer[512] = {0};
 struct MojomBuffer buf = {byte_buffer, sizeof(byte_buffer), 0};
 
 // First allocate space for the example_Person struct:
 struct example_Person* person =
    (struct example_Person*)MojomBuffer_Allocate(&buf, sizeof(struct example_Person));
-   
+
 // Allocate enough space for a 10 character string.
 person->name.ptr = (struct MojomStringHeader*)MojomBuffer_Allocate(
     &buf,
     sizeof(struct MojomStringHeader) + 10);
 ```
 
 We can extract how much buffer space was used by reading `buf.num_byes_used`.
 
 Along with the C struct, there are some functions generated that help encode and
 decode mojom structs, amongst other things.  For the `example.Person` mojom
 struct, the following functions are generated:
 
 ```c
 struct example_Person* example_Person_DeepCopy(
   struct MojomBuffer* in_buffer,
   struct example_Person* in_data);
-  
+
 void example_Person_EncodePointersAndHandles(
   struct example_Person* inout_struct, uint32_t in_struct_size,
   struct MojomHandleBuffer* inout_handle_buffer);
-  
+
 void example_Person_DecodePointersAndHandles(
   struct example_Person* inout_struct, uint32_t in_struct_size,
   MojomHandle inout_handles[], uin32_t in_num_handles);
 
 MojomValidationResult example_Person_Validate(
   const struct example_Person* in_struct, uint32_t in_struct_size,
   uint32_t in_num_handles);
 ```
 
 The generated `example_Person_DeepCopy(..)`  function is used to copy over the
@@ skipping 110 matching lines @@
 
 If valid, it is safe to look at the `request_id` in `struct MojomMessage`, and
 the `ordinal` describing the message. By checking if it's any of
 `example_EmployeeRegistry_*__Ordinal`, you can further validate that it is a
 request or expects a response. See `bindings/message.h` for more functions that
 help validate message headers. Once the message header is fully validated, you
 must also validate the request or response mojom struct following the message
 header using the generated `*_Validate(..)` function.
 
 Note that validation is run on encoded messages and structs on the wire --
-decoding a struct without validating it first is dangerous. 
+decoding a struct without validating it first is dangerous.
 
 ## Enums and Constants
 
 Example mojom code:
 ``` mojom
 module example;
 
 enum MyEnum { Zero, One, Four = 4, Five };
 const uint64 kMyConst = 34;
 ```
@@ skipping 119 matching lines @@
 
 ## Maps
 
 Maps on the wire are mojom structs with two arrays; one for the keys, and one
 for the values. The `i`th element in the keys array corresponds to the `i`th
 element in the values array. As such, both arrays must have the same number
 of elements, and neither may be null.
 
 # Additional Readings
 * [Internals of the generated bindings](INTERNALS.md)