Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(273)

Unified Diff: mojo/public/c/docs/bindings/TUTORIAL.md

Issue 2248963003: Remove some end-of-line whitespace. (Closed) Base URL: https://github.com/domokit/mojo.git@master
Patch Set: Created 4 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: mojo/public/c/docs/bindings/TUTORIAL.md
diff --git a/mojo/public/c/docs/bindings/TUTORIAL.md b/mojo/public/c/docs/bindings/TUTORIAL.md
index a7b4519bbad1f8d259bb952da21bbb2a145016c6..629f185e9771079df30e3b1b84f70f41a47438e6 100644
--- a/mojo/public/c/docs/bindings/TUTORIAL.md
+++ b/mojo/public/c/docs/bindings/TUTORIAL.md
@@ -61,13 +61,13 @@ 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:
@@ -78,7 +78,7 @@ 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,
@@ -95,11 +95,11 @@ struct, the following functions are generated:
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);
@@ -230,7 +230,7 @@ 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
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698