Fix typos and clarify grammar and word choice throughout the OSS-Fuzz docs. (#363)

9 files changed, 33 insertions, 33 deletions

diff --git a/README.md b/README.md
index fa3dea98..c1cbd0f1 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # OSS-Fuzz - Continuous Fuzzing for Open Source Software
 
-> *Status*: Beta. We are now accepting applications from widely used open source projects.
+> *Status*: Beta. We are now accepting applications from widely-used open source projects.
 
 [FAQ](docs/faq.md)
 | [Ideal Fuzzing Integration](docs/ideal_integration.md)
@@ -32,7 +32,7 @@ At the first stage of the project we use
 [libFuzzer](http://llvm.org/docs/LibFuzzer.html) with
 [Sanitizers](https://github.com/google/sanitizers). More fuzzing engines will be added later.
 [ClusterFuzz](docs/clusterfuzz.md)
-provides distributed fuzzer execution environment and reporting.
+provides a distributed fuzzer execution environment and reporting.
 
 Currently OSS-Fuzz supports C and C++ code (other languages supported by [LLVM](http://llvm.org) may work too).
 
@@ -47,7 +47,7 @@ and [integrates](docs/ideal_integration.md) them with the project's build and te
 - When [ClusterFuzz](docs/clusterfuzz.md) finds a bug, an issue is automatically
   reported in the OSS-Fuzz [issue tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list) 
   ([example](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9)).
-  ([Why different tracker?](docs/faq.md#why-do-you-use-a-different-issue-tracker-for-reporting-bugs-in-oss-projects)).
+  ([Why use a different tracker?](docs/faq.md#why-do-you-use-a-different-issue-tracker-for-reporting-bugs-in-oss-projects)).
   Project owners are CC-ed to the bug report.
 - The project developer fixes the bug upstream and credits OSS-Fuzz for the discovery (commit message should contain
   the string **'Credit to OSS-Fuzz'**).
@@ -72,7 +72,7 @@ To submit a new project:
     If this is not you or the email address differs from VCS, an informal e-mail verification will be required.
   * Note that `project_name` can only contain alphanumeric characters, underscores(_) or dashes(-).
 - Once accepted by an OSS-Fuzz project member, follow the [New Project Guide](docs/new_project_guide.md)
-  to write the code.
+  to configure your project.
 
 
 ## Bug Disclosure Guidelines
@@ -80,7 +80,7 @@ To submit a new project:
 Following [Google's standard disclosure policy](https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html)
 OSS-Fuzz will adhere to following disclosure principles:
   - **90-day deadline**. After notifying project authors, we will open reported
-    issues in 90 days, or 7 days after the fix is released.
+    issues to the public in 90 days, or 7 days after the fix is released.
   - **Weekends and holidays**. If a deadline is due to expire on a weekend,
     the deadline will be moved to the next normal work day.
   - **Grace period**. We have a 14-day grace period. If a 90-day deadline
@@ -97,9 +97,9 @@ OSS-Fuzz will adhere to following disclosure principles:
 * [Accessing corpora](docs/corpora.md) describes how to access the corpora we use for fuzzing.
 * [Fuzzer execution environment](docs/fuzzer_environment.md) documents the
   environment under which your fuzzers will be run.
-* [Projects](projects) lists OSS projects currently added to OSS-Fuzz.
+* [Projects](projects) lists OSS projects currently analyzed by OSS-Fuzz.
 * [Chrome's Efficient Fuzzer Guide](https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md) 
-  while contains some chrome-specifics, is an excellent documentation on making your fuzzer better.
+  while containing some Chrome-specific bits, is an excellent guide to making your fuzzer better.
 * Blog posts: 2016-12-01 ([1](https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html),
 [2](https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html),
 [3](https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html))
@@ -111,7 +111,7 @@ gives the latest build logs for each project.
 ## Trophies
 
 [This page](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=status%3AFixed%2CVerified+Type%3ABug%2CBug-Security+-component%3AInfra+)
-gives a list of publically viewable fixed bugs found by OSS-Fuzz.
+gives a list of publicly-viewable fixed bugs found by OSS-Fuzz.
 
 ## References
 * [libFuzzer documentation](http://libfuzzer.info)
diff --git a/docs/corpora.md b/docs/corpora.md
index 4ddc76f1..0c437745 100644
--- a/docs/corpora.md
+++ b/docs/corpora.md
@@ -5,7 +5,7 @@ If you would like to access the corpora that we are using for your fuzz targets
 ## Install Google Cloud SDK
 
 The corpora for fuzz targets are stored on [Google Cloud Storage](https://cloud.google.com/storage/). To access them, you will need to [install](https://cloud.google.com/storage/docs/gsutil_install) the gsutil tool, which is part of the Google Cloud SDK.
-Follow the instructions on the installation page to login with a Google account thats listed in your project's `project.yaml`.
+Follow the instructions on the installation page to login with a Google account listed in your project's `project.yaml` file.
 
 ## Viewing the corpus for a fuzz target
 
diff --git a/docs/faq.md b/docs/faq.md
index 4526ba80..4fef8ff3 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -15,7 +15,7 @@ to accept your project at this time!
 ## Why do you use a [different issue tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list) for reporting bugs in OSS projects?
 
 Security access control is important for the kind of issues that OSS-Fuzz detects.
-We will reconsider github issue tracker once the
+We will reconsider the Github issue tracker once the
 [access control feature](https://github.com/isaacs/github/issues/37) is available.
 
 ## Why do you require an e-mail associated with a Google account?
@@ -27,8 +27,8 @@ with a Google account.
 ## Why do you use Docker?
 
 Building fuzzers requires building your project with a fresh Clang compiler and special compiler flags. 
-An easy-to-use Docker image is provided to simplify toolchain distribution. This also limits our exposure
-to a multitude of Linux varieties and provides a reproducible and secure environment for fuzzer
+An easy-to-use Docker image is provided to simplify toolchain distribution. This also simplifies our
+support for a variety of Linux distributions and provides a reproducible and secure environment for fuzzer
 building and execution.
 
 ## How do you handle timeouts and OOMs?
@@ -53,13 +53,13 @@ Currently we do not offer ways to change the memory and time limits.
 
 ## Can I launch an additional process (e.g. a daemon) from my fuzz target?
 
-No. In order to get all the benefits of in-process coverage guided fuzz testing,
+No. In order to get all the benefits of in-process, coverage-guided fuzz testing,
 it is required to run everything inside a single process. Any child processes created
 outside the main process introduces heavy launch overhead and is not monitored for
 code coverage.
 
 Another rule of thumb is: "the smaller fuzz target is, the better it is". It is
-expected to have many fuzz targets to test different components in your project,
+expected that your project will have many fuzz targets to test different components,
 instead of a single fuzz target trying to cover everything. Think of fuzz target
 as a unit test, though it is much more powerful since it helps to test millions
 of data permutations rather than just one.
diff --git a/docs/fuzzer_environment.md b/docs/fuzzer_environment.md
index d433ff2f..0907cfe4 100644
--- a/docs/fuzzer_environment.md
+++ b/docs/fuzzer_environment.md
@@ -5,14 +5,14 @@ Your fuzz targets will be run on a [Google Compute Engine](https://cloud.google.
 ## Runtime Dependencies
 
 You should not make any assumptions on the availability of dependent packages 
-in the execution environment. Packages that are installed in 
+in the execution environment. Packages that are installed via
 [Dockerfile](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#dockerfile)
 or built as part of 
 [build.sh](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#buildsh)
-are not available on the bot runtime environment (that run the fuzz targets).
+are not available on the bot runtime environment (where the fuzz targets run).
 
 If you need these dependencies in the runtime environment, you can either
-- Install the packages in Dockerfile
+- Install the packages via Dockerfile
 ([example](https://github.com/google/oss-fuzz/blob/master/projects/tor/Dockerfile#L19))
 and then link statically against them
 ([example](https://github.com/google/oss-fuzz/blob/master/projects/tor/build.sh#L40))
@@ -20,7 +20,7 @@ and then link statically against them
 [build.sh](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#buildsh)
 ([example](https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/build.sh#L26)).
 
-All build artifacts needed during fuzz target execution should be inside `$OUT` 
+All build artifacts needed during fuzz target execution should be inside the `$OUT`
 directory. Only those artifacts are archived and used on the bots. Everything else
 is ignored (e.g. artifacts in `$WORK`, `$SRC`, etc) and hence is not available
 in the execution environment.
diff --git a/docs/glossary.md b/docs/glossary.md
index fa139a39..cb4272fd 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -1,10 +1,10 @@
 # Glossary
 
-Naming things is hard, so this page tries to reduce confusion around fuzzing related terminology.
+Naming things is hard, so this page tries to reduce confusion around fuzzing-related terminology.
 
 ## Corpus
 Or **test corpus**, or **fuzzing corpus**.<BR>
-A set of [test inputs](#test-input). In most contexts, it is also referred to a set of minimal test inputs that generate maximal code coverage.
+A set of [test inputs](#test-input). In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.
 
 ## Fuzz Target
 Or **Target Function**, or **Fuzzing Target Function**, or **Fuzzing Entry Point**.<BR>
@@ -37,7 +37,7 @@ See related terms [Mutation Engine](#mutation-engine) and [Test Generator](#test
 ## Job type
 
 Or **Fuzzer Build**.<BR>
-A [ClusterFuzz](clusterfuzz.md) specific term.
+A [ClusterFuzz](clusterfuzz.md)-specific term.
 This refers to a build that contains all the [fuzz targets](#fuzz-target) for a given [project](#project), is run 
 with a specific [fuzzing engine](#fuzzing-engine), in a specific build mode (e.g. with enabled/disabled assertions), 
 and optionally combined with a [sanitizer](#sanitizer).
@@ -53,7 +53,7 @@ Example: [radamsa](https://github.com/aoh/radamsa) (a generic test mutator).
 
 ## Project
 
-A project is an open source software that is integrated with OSS-Fuzz. 
+A project is an open source software project that is integrated with OSS-Fuzz.
 Each project has a single set of configuration files 
 (example: [expat](https://github.com/google/oss-fuzz/tree/master/projects/expat)) and 
 may have one or more [fuzz targets](#fuzz-target) 
@@ -81,4 +81,4 @@ Examples:
 
 ## Test Input
 A sequence of bytes that is used as input to a [fuzz target](#fuzz-target). 
-Typicaly, a test input is stored in a separate file. 
+Typically, a test input is stored in a separate file.
diff --git a/docs/ideal_integration.md b/docs/ideal_integration.md
index 9422d6f1..cae51849 100644
--- a/docs/ideal_integration.md
+++ b/docs/ideal_integration.md
@@ -13,7 +13,7 @@ All fuzz targets should be easily discoverable (e.g. reside in the same director
 This makes it easy to maintain the fuzzers and minimizes breakages that can arise as source code changes over time.
 
 Make sure to fuzz the target locally for a small period of time to ensure that 
-it does not crash, hang, or runs out of memory instantly. 
+it does not crash, hang, or run out of memory instantly.
 See details at http://libfuzzer.info and http://tutorial.libfuzzer.info.
 
 The interface between the [fuzz target]((http://libfuzzer.info/#fuzz-target))
@@ -35,8 +35,8 @@ Examples:
 The *corpus* is a set of inputs for the fuzz target (stored as individual files). 
 When starting the fuzzing process, one should have a "seed corpus", 
 i.e. a set of inputs to "seed" the mutations.
-The quality of the seed corpus has a huge impact on the fuzzing efficiency as it allows the fuzzer
-to discover new code paths easier. 
+The quality of the seed corpus has a huge impact on fuzzing efficiency as it allows the fuzzer
+to discover new code paths more easily.
 
 The ideal corpus is a minimal set of inputs that provides maximal code coverage. 
 
@@ -51,7 +51,7 @@ Examples:
 
 
 ## Regression Testing
-The fuzz targets should be regularly tested (not necessary fuzzed!) as a part of the project's regression testing process.
+The fuzz targets should be regularly tested (not necessarily fuzzed!) as a part of the project's regression testing process.
 One way to do so is to link the fuzz target with a simple driver
 (e.g. [this one](https://github.com/llvm-mirror/llvm/tree/master/lib/Fuzzer/standalone))
 that runs the provided inputs and use this driver with the seed corpus created in previous step. 
diff --git a/docs/new_project_guide.md b/docs/new_project_guide.md
index a4fd9833..5b2fe4b7 100644
--- a/docs/new_project_guide.md
+++ b/docs/new_project_guide.md
@@ -1,4 +1,4 @@
-# Setting up New Project
+# Setting up a New Project
 
 ## Prerequisites
 - [Integrate](ideal_integration.md) one or more [Fuzz Targets](glossary.md#fuzz-target)
@@ -207,7 +207,7 @@ has an appropriate and consistent license.
 
 ### Dictionaries
 
-Dictionaries hugely improve fuzzing effeciency for inputs with lots of similar
+Dictionaries hugely improve fuzzing efficiency for inputs with lots of similar
 sequences of bytes. [libFuzzer documentation](http://libfuzzer.info#dictionaries)
 
 Put your dict file in `$OUT` and specify in .options file:
@@ -224,7 +224,7 @@ to reuse the same dictionary if they are fuzzing very similar inputs.
 ## project.yaml
 
 This file stores the metadata about your project. This includes things like project's homepage,
-list of sanitizers used, list of ccs on newly filed bugs, etc.
+list of sanitizers used, list of CCs on newly-filed bugs, etc.
 (example: [expat](https://github.com/google/oss-fuzz/blob/master/projects/expat/project.yaml)).
 
 ## Checking in to OSS-Fuzz repository
diff --git a/docs/reference.md b/docs/reference.md
index 5e7a35f9..e5930191 100644
--- a/docs/reference.md
+++ b/docs/reference.md
@@ -3,7 +3,7 @@
 ## Sanitizers
 
 Fuzzers are usually built with one or more  [sanitizer](https://github.com/google/sanitizers) enabled. 
-You can select sanitizer configuration by specifying `$SANITIZER` build environment varible using `-e` option:
+You can select sanitizer configuration by specifying `$SANITIZER` build environment variable using `-e` option:
 
 ```bash
 python infra/helper.py build_fuzzers -e SANITIZER=undefined json
@@ -15,7 +15,7 @@ Supported sanitizers:
 | ------------ | ----------
 | `address` *(default)* | [Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) with [Leak Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer).
 | `undefined` | [Undefined Behavior Sanitizer](http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).
-| `memory` | [Memory Sanitizer](https://github.com/google/sanitizers/wiki/MemorySanitizer).<br/>*NOTE: It is critical that you build __all__ the code in your program (including libraries it uses) with memory sanitizer. Otherwise, you will see false positive crashes due to inability to see initializations in uninstrumented code.*
+| `memory` | [Memory Sanitizer](https://github.com/google/sanitizers/wiki/MemorySanitizer).<br/>*NOTE: It is critical that you build __all__ the code in your program (including libraries it uses) with Memory Sanitizer. Otherwise, you will see false positive crashes due to an inability to see initializations in uninstrumented code.*
 
 Compiler flag values for predefined configurations are specified in the [Dockerfile](../infra/base-images/base-builder/Dockerfile). 
 These flags can be overriden by specifying `$SANITIZER_FLAGS` directly.
diff --git a/docs/reproducing.md b/docs/reproducing.md
index d8039f6a..2e7f0e15 100644
--- a/docs/reproducing.md
+++ b/docs/reproducing.md
@@ -35,7 +35,7 @@ $ python infra/helper.py build_fuzzers -e SANITIZER=<address/memory/undefined> $
 $ python infra/helper.py reproduce $PROJECT_NAME <fuzz_target_name> <testcase_path>
 ```
 
-  It builds the fuzzer from the most recent successful OSS-Fuzz build (usually last night's sources)
+  This builds the fuzzer from the most recent successful OSS-Fuzz build (usually last night's sources)
   and feeds the testcase file to the target function. 
   
   E.g. for building [libxml2](../projects/libxml2) project with UndefinedBehaviorSanitizer instrumentation