Merge pull request #361 from radarhere/master

Fixed typos

c++/src/capnp/arena.h

@@ -123,7 +123,7 @@ public:
   // though no actual pointer was traversed. This is used e.g. when reading a struct list pointer
   // where the element sizes are zero -- the sender could set the list size arbitrarily high and
   // cause the receiver to iterate over this list even though the message itself is small, so we
-  // need to defend agaisnt DoS attacks based on this.
+  // need to defend against DoS attacks based on this.
 
   inline Arena* getArena();
   inline SegmentId getSegmentId();

c++/src/capnp/serialize.h

@@ -116,7 +116,7 @@ size_t expectedSizeInWordsFromPrefix(kj::ArrayPtr<const word> messagePrefix);
 // If the returned value is greater than `messagePrefix.size()`, then the message is not yet
 // complete and the app cannot parse it yet. If the returned value is less than or equal to
 // `messagePrefix.size()`, then the returned value is the exact total size of the message; any
-// remaining bytes are part of the next mesasge.
+// remaining bytes are part of the next message.
 //
 // This function is useful when reading messages from a stream in an asynchronous way, but when
 // using the full KJ async infrastructure would be too difficult. Each time bytes are received,

doc/_posts/2013-08-12-capnproto-0.2-no-more-haskell.md

@@ -48,7 +48,7 @@ a whole separate module and ending up with thousands of source files.  I want to
 a list of objects of varying types that implement the same interface without having to re-invent
 virtual tables every time I do it (type classes don't quite solve the problem).
 
-And as it turns out, even aside from the lack of object-orientation, I don't acutally like
+And as it turns out, even aside from the lack of object-orientation, I don't actually like
 functional programming as much as I thought.  Yes, writing my parser was super-easy (my first
 commit message was
 "[Day 1: Learn Haskell, write a parser](https://github.com/kentonv/capnproto/commit/6bb49ca775501a9b2c7306992fd0de53c5ee4e95)").

doc/_posts/2014-06-17-capnproto-flatbuffers-sbe.md

@@ -60,7 +60,7 @@ SBE, however, as far as I can tell from reading the code, does not allow you to
 
 The central thesis of all three competitors is that data should be structured the same way in-memory and on the wire, thus avoiding costly encode/decode steps.
 
-Protobufs reperesents the old way of thinking.
+Protobufs represents the old way of thinking.
 
 **Random-access reads**
 
@@ -136,7 +136,7 @@ SBE uses XML schemas, which are verbose.
 
 Protobuf generated classes have often been (ab)used as a convenient way to store an application's mutable internal state. There's mostly no problem with modifying a message gradually over time and then serializing it when needed.
 
-This usage pattern does not work well with any zero-copy serialization format because these formats must use arena-style allocation to make sure the message is built in contiguous memory. Arena allocation has the property that you cannot free any object unless you free the entire arena. Therefore, when objects are discarded, the memory ends up leaked until the message as a whole is destoryed. A long-lived message that is modified many times will thus leak memory.
+This usage pattern does not work well with any zero-copy serialization format because these formats must use arena-style allocation to make sure the message is built in contiguous memory. Arena allocation has the property that you cannot free any object unless you free the entire arena. Therefore, when objects are discarded, the memory ends up leaked until the message as a whole is destroyed. A long-lived message that is modified many times will thus leak memory.
 
 **Padding takes space on wire?**
 

doc/_posts/2015-03-02-security-advisory-and-integer-overflow-protection.md

@@ -37,7 +37,7 @@ It is our policy that any time a security problem is found, we will not only fix
 4. We will continue to require that all tests (including the new fuzz test) run
    cleanly under Valgrind before each release.
 5. We will commission a professional security review before any 1.0 release.
-   Until that time, we continue to recommend agaisnt using Cap'n Proto to
+   Until that time, we continue to recommend against using Cap'n Proto to
    interpret data from potentially-malicious sources.
 
 I am pleased to report that measures 1, 2, and 3 all detected both integer overflow/underflow problems, and AFL additionally detected the CPU amplification problem.

doc/capnp-tool.md

@@ -77,5 +77,5 @@ written as several separate files with a master file that imports the rest.
 
 Such a configuration should be compiled to binary format using `capnp eval` before deployment,
 in order to verify that there are no errors and to make deployment easier and faster.  While you
-could techincally ship the text configs to production and have the servers parse them directly
+could technically ship the text configs to production and have the servers parse them directly
 (e.g. with `capnp::SchemaParser`), encoding before deployment is more efficient and robust.

doc/encoding.md

@@ -108,7 +108,7 @@ Fields are positioned within the struct according to an algorithm with the follo
 * The position of each field depends only on its definition and the definitions of lower-numbered
   fields, never on the definitions of higher-numbered fields.  This ensures backwards-compatibility
   when new fields are added.
-* Due to alignment reqirements, fields in the data section may be separated by padding.  However,
+* Due to alignment requirements, fields in the data section may be separated by padding.  However,
   later-numbered fields may be positioned into the padding left between earlier-numbered fields.
   Because of this, a struct will never contain more than 63 bits of padding.  Since objects are
   rounded up to a whole number of words anyway, padding never ends up wasting space.
@@ -165,7 +165,7 @@ A struct list must always be written using C = 7. However, a list of any element
 C = 1, i.e. 1-bit) may be *decoded* as a struct list, with each element being interpreted as being
 a prefix of the struct data. For instance, a list of 2-byte values (C = 3) can be decoded as a
 struct list where each struct has 2 bytes in their "data" section (and an empty pointer section). A
-list of pointer values (C = 6) can be decoded as a struct list where each sturct has a pointer
+list of pointer values (C = 6) can be decoded as a struct list where each struct has a pointer
 section with one pointer (and an empty data section). The purpose of this rule is to make it
 possible to upgrade a list of primitives to a list of structs, as described under the
 [protocol evolution rules](language.html#evolving-your-protocol).

doc/index.md

@@ -97,7 +97,7 @@ Note that I no longer work for Google. Cap'n Proto is not, and never has been, a
 To install Cap'n Proto, head over to the [installation page](install.html).  If you'd like to help
 hack on Cap'n Proto, such as by writing bindings in other languages, let us know on the
 [discussion group](https://groups.google.com/group/capnproto).  If you'd like to receive e-mail
-udpates about future releases, add yourself to the
+updates about future releases, add yourself to the
 [announcement list](https://groups.google.com/group/capnproto-announce).
 
 {% include buttons.html %}

doc/language.md

@@ -674,7 +674,7 @@ annotation qux @0xf8a1bedf44c89f00 (field) :Text;
 
 If you omit the ID for a type or annotation, one will be assigned automatically.  This default
 ID is derived by taking the first 8 bytes of the MD5 hash of the parent scope's ID concatenated
-with the declaration's name (where the "parent scope" is the file for top-level delarations, or
+with the declaration's name (where the "parent scope" is the file for top-level declarations, or
 the outer type for nested declarations).  You can see the automatically-generated IDs by "compiling"
 your file with the `-ocapnp` flag, which echos the schema back to the terminal annotated with
 extra information, e.g. `capnp compile -ocapnp myschema.capnp`.  In general, you would only specify
@@ -760,7 +760,7 @@ without changing the [canonical](encoding.html#canonicalization) encoding of a m
 
   (This rule applies analogously to generic methods.)
 
-The following changes are backwards-compatible but may change the canonical encoding of a mesasge.
+The following changes are backwards-compatible but may change the canonical encoding of a message.
 Apps that rely on canonicalization (such as some cryptographic protocols) should avoid changes in
 this list, but most apps can safely use them: