Fix various missed issues - 1st run

docs/afl-fuzz_approach.md

@@ -468,7 +468,8 @@ cd ../../
 sudo make install
 ```
 
-To learn more about remote monitoring and metrics visualization with StatsD, see [rpc_statsd.md](rpc_statsd.md).
+To learn more about remote monitoring and metrics visualization with StatsD, see
+[rpc_statsd.md](rpc_statsd.md).
 
 ### Addendum: status and plot files
 
@@ -524,9 +525,9 @@ into each of them or deploy scripts to read the fuzzer statistics. Using
 `AFL_STATSD` (and the other related environment variables `AFL_STATSD_HOST`,
 `AFL_STATSD_PORT`, `AFL_STATSD_TAGS_FLAVOR`) you can automatically send metrics
 to your favorite StatsD server. Depending on your StatsD server, you will be
-able to monitor, trigger alerts, or perform actions based on these metrics (e.g:
-alert on slow exec/s for a new build, threshold of crashes, time since last
-crash > X, etc.).
+able to monitor, trigger alerts, or perform actions based on these metrics
+(e.g.: alert on slow exec/s for a new build, threshold of crashes, time since
+last crash > X, etc.).
 
 The selected metrics are a subset of all the metrics found in the status and in
 the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`,
@@ -537,6 +538,6 @@ the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`,
 definitions can be found in the addendum above.
 
 When using multiple fuzzer instances with StatsD, it is *strongly* recommended
-to setup the flavor (AFL_STATSD_TAGS_FLAVOR) to match your StatsD server. This
+to setup the flavor (`AFL_STATSD_TAGS_FLAVOR`) to match your StatsD server. This
 will allow you to see individual fuzzer performance, detect bad ones, see the
 progress of each strategy...

docs/custom_mutators.md

@@ -276,7 +276,7 @@ gcc -shared -Wall -O3 example.c -o example.so
 ```
 
 Note that if you specify multiple custom mutators, the corresponding functions
-will be called in the order in which they are specified. e.g. first
+will be called in the order in which they are specified. E.g., the first
 `post_process` function of `example_first.so` will be called and then that of
 `example_second.so`.
 

docs/env_variables.md

@@ -585,7 +585,7 @@ The FRIDA wrapper used to instrument binary-only code supports many of the same
 options as `afl-qemu-trace`, but also has a number of additional advanced
 options. These are listed in brief below (see
 [frida_mode/README.md](../frida_mode/README.md) for more details). These
-settings are provided for compatibiltiy with QEMU mode, the preferred way to
+settings are provided for compatibility with QEMU mode, the preferred way to
 configure FRIDA mode is through its [scripting](../frida_mode/Scripting.md)
 support.
 

docs/features.md

@@ -1,7 +1,7 @@
 # Important features of AFL++
 
 AFL++ supports llvm from 3.8 up to version 12, very fast binary fuzzing with
-QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full
+QEMU 5.1 with laf-intel and redqueen, FRIDA mode, unicorn mode, gcc plugin, full
 *BSD, Mac OS, Solaris and Android support and much, much, much more.
 
 | Feature/Instrumentation  | afl-gcc | llvm      | gcc_plugin | FRIDA mode(9)    | QEMU mode(10)    |unicorn_mode(10)  |coresight_mode(11)|
@@ -30,7 +30,7 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full
    versions that write to a file to use with afl-fuzz' `-x`
 8. the snapshot LKM is currently unmaintained due to too many kernel changes
    coming too fast :-(
-9. frida mode is supported on Linux and MacOS for Intel and ARM
+9. FRIDA mode is supported on Linux and MacOS for Intel and ARM
 10. QEMU/Unicorn is only supported on Linux
 11. Coresight mode is only available on AARCH64 Linux with a CPU with Coresight
     extension