removed trailing whitespaces

2 files changed, 26 insertions, 26 deletions

diff --git a/docs/new_project_guide.md b/docs/new_project_guide.md
index d7c589f9..788fecec 100644
--- a/docs/new_project_guide.md
+++ b/docs/new_project_guide.md
@@ -3,7 +3,7 @@
 ## Prerequisites
 - [Integrate](ideal_integration.md) one or more [Fuzz Targets](glossary.md#fuzz-target)
   with the project you want to fuzz.<BR>
-  Examples: 
+  Examples:
 [boringssl](https://github.com/google/boringssl/tree/master/fuzz),
 [SQLite](https://www.sqlite.org/src/artifact/ad79e867fb504338),
 [s2n](https://github.com/awslabs/s2n/tree/master/tests/fuzz),
@@ -19,21 +19,21 @@
 
 ## Overview
 
-To add a new OSS project to OSS-Fuzz, you need a project subdirectory 
-inside the [`projects/`](../projects) directory in [OSS-Fuzz repository](https://github.com/google/oss-fuzz). 
-Example: [boringssl](https://github.com/google/boringssl) project is located in 
+To add a new OSS project to OSS-Fuzz, you need a project subdirectory
+inside the [`projects/`](../projects) directory in [OSS-Fuzz repository](https://github.com/google/oss-fuzz).
+Example: [boringssl](https://github.com/google/boringssl) project is located in
 [`projects/boringssl`](../projects/boringssl).
 
 The project directory needs to contain the following three configuration files:
 
-* `projects/<project_name>/Dockerfile` - defines the container environment with information 
+* `projects/<project_name>/Dockerfile` - defines the container environment with information
 on dependencies needed to build the project and its [fuzz targets](glossary.md#fuzz-target).
-* `projects/<project_name>/build.sh` - build script that executes inside the container and 
+* `projects/<project_name>/build.sh` - build script that executes inside the container and
 generates project build.
 * `projects/<project_name>/project.yaml` - provides metadata about the project.
 
-To *automatically* create a new directory for your project and 
-generate templated versions of these configuration files, 
+To *automatically* create a new directory for your project and
+generate templated versions of these configuration files,
 run the following set of commands:
 
 ```bash
@@ -46,7 +46,7 @@ It is preferred to keep and maintain [fuzz targets](glossary.md#fuzz-target) in
 
 ## Dockerfile
 
-This file defines the Docker image definition. This is where the build.sh script will be executed in. 
+This file defines the Docker image definition. This is where the build.sh script will be executed in.
 It is very simple for most projects:
 ```docker
 FROM ossfuzz/base-libfuzzer               # base image with clang toolchain
@@ -65,16 +65,16 @@ your [fuzz targets](glossary.md#fuzz-target) will run on ClusterFuzz, and the as
 
 ## build.sh
 
-This file describes how to build [fuzz targets](glossary.md#fuzz-target) for your project. 
+This file describes how to build [fuzz targets](glossary.md#fuzz-target) for your project.
 The script will be executed within the image built from `Dockerfile`.
 
 In general, this script will need to:
 
-1. Build the project using your build system *with* correct compiler and its flags provided as 
-  *environment variables* (see below). 
+1. Build the project using your build system *with* correct compiler and its flags provided as
+  *environment variables* (see below).
 2. Build the [fuzz targets](glossary.md#fuzz-target), linking your project's build and libFuzzer.
    Resulting binaries should be placed in `$OUT`.
-   
+
 *Note*: The binary names for your fuzz targets must only contain alphanumeric characters, underscore(_) or dash(-).
 They will not run on our infrastructure otherwise.
 
@@ -97,7 +97,7 @@ $CXX $CXXFLAGS -std=c++11 -Ilib/ \
 cp $SRC/*.dict $SRC/*.options $OUT/
 ```
 
-### build.sh Script Environment 
+### build.sh Script Environment
 
 When build.sh script is executed, the following locations are available within the image:
 
@@ -119,7 +119,7 @@ These flags are provided in the following environment variables:
 Most well-crafted build scripts will automatically use these variables. If not,
 pass them manually to the build tool.
 
-See [Provided Environment Variables](../infra/base-images/base-libfuzzer/README.md#provided-environment-variables) section in 
+See [Provided Environment Variables](../infra/base-images/base-libfuzzer/README.md#provided-environment-variables) section in
 `base-libfuzzer` image documentation for more details.
 
 
@@ -134,7 +134,7 @@ $ python infra/helper.py build_fuzzers $PROJECT_NAME
 ```
 
 This should place the built binaries into `/path/to/oss-fuzz/build/out/$PROJECT_NAME`
-directory on your machine (and `$OUT` in the container). You should then try to run these binaries 
+directory on your machine (and `$OUT` in the container). You should then try to run these binaries
 inside the container to make sure that they work properly:
 
 ```bash
@@ -144,7 +144,7 @@ $ python infra/helper.py run_fuzzer $PROJECT_NAME <fuzz_target>
 If everything works locally, then it should also work on our automated builders
 and ClusterFuzz.
 
-It's recommended to look at code coverage as a sanity check to make sure that 
+It's recommended to look at code coverage as a sanity check to make sure that
 [fuzz target](glossary.md#fuzz-target) gets to the code you expect.
 
 ```bash
@@ -172,7 +172,7 @@ max_len = 1024
 [List of available options](http://llvm.org/docs/LibFuzzer.html#options). Use of `max_len` is highly recommended.
 
 For out of tree [fuzz targets](glossary.md#fuzz-target), you will likely add options file using docker's
-`COPY` directive and will copy it into output in build script. 
+`COPY` directive and will copy it into output in build script.
 (example: [woff2](https://github.com/google/oss-fuzz/blob/master/projects/woff2/convert_woff2ttf_fuzzer.options)).
 
 
@@ -182,10 +182,10 @@ OSS-Fuzz uses evolutionary fuzzing algorithms. Supplying seed corpus consisting
 of good sample inputs is one of the best ways to improve [fuzz target](glossary.md#fuzz-target)'s coverage.
 
 To provide a corpus for `my_fuzzer`, put `my_fuzzer_seed_corpus.zip` file next
-to the [fuzz target](glossary.md#fuzz-target)'s binary in `$OUT` during the build. Individual files in this 
-archive will be used as starting inputs for mutations. You can store the corpus 
-next to source files, generate during build or fetch it using curl or any other 
-tool of your choice. 
+to the [fuzz target](glossary.md#fuzz-target)'s binary in `$OUT` during the build. Individual files in this
+archive will be used as starting inputs for mutations. You can store the corpus
+next to source files, generate during build or fetch it using curl or any other
+tool of your choice.
 (example: [boringssl](https://github.com/google/oss-fuzz/blob/master/projects/boringssl/build.sh#L41)).
 
 Seed corpus files will be used for cross-mutations and portions of them might appear
@@ -211,8 +211,8 @@ 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. 
+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.
 (example: [expat](https://github.com/google/oss-fuzz/blob/master/projects/expat/project.yaml)).
 
 ## Checking in to OSS-Fuzz repository
@@ -248,6 +248,6 @@ If you are porting a fuzz target from Chromium, keep the original Chromium licen
 ## The end
 
 Once your change is merged, your project and fuzz targets should be automatically built and run on
-ClusterFuzz after a short while (&lt; 1 day)!<BR><BR> 
+ClusterFuzz after a short while (&lt; 1 day)!<BR><BR>
 Check your project's build status [here](https://oss-fuzz-build-logs.storage.googleapis.com/status.html).<BR>
 Check out the crashes generated and code coverage statistics on [ClusterFuzz](clusterfuzz.md) web interface [here](https://clusterfuzz-external.appspot.com/).
diff --git a/infra/base-images/base-libfuzzer/README.md b/infra/base-images/base-libfuzzer/README.md
index d7c44b19..d69f94f7 100644
--- a/infra/base-images/base-libfuzzer/README.md
+++ b/infra/base-images/base-libfuzzer/README.md
@@ -85,7 +85,7 @@ pass them manually to the build tool.
 ## Sources
 
 Child image has to checkout all sources that it needs to compile fuzz targets into
-`$SRC` directory. When the image is executed, a directory could be mounted on top 
+`$SRC` directory. When the image is executed, a directory could be mounted on top
 of these with local checkouts using
 `docker run -v $HOME/my_project:/src/my_project ...`.