fixed examples and added a finalized PNG for #3 double-free

Author: JimRadigan

docs/sanitizers/SRC_CODE/double-free/example3.PNG

@@ -8,7 +8,7 @@ help viewer_keywords: ["ASan","AddressSanitizer","Address Sanitizer","ASan examp
 
 # Double free
 
-In `C`, you can call `free()` erroneously. In `C++`, you can call delete more than once. In the following examples, we show errors with `delete`, `free()` and `HeapCreate()`. Sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).
+In `C`, you can call `free()` erroneously. In `C++`, you can call `delete` more than once. In the following examples, we show errors with `delete`, `free()` and `HeapCreate()`. Sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).
 
 ## Example C++ - double operator delete
 
@@ -57,7 +57,6 @@ int main(int argc, char **argv) {
   return res;
 }
 
-
 ```
 
 From a **Developer Command Prompt**:

docs/sanitizers/examples-double-free.md

@@ -8,14 +8,12 @@ help viewer_keywords: ["ASan","AddressSanitizer","Address Sanitizer","ASan examp
 
 # Global buffer overflow
 
-The compiler generates metadata for any variable in the `.data` or `.bss` sections. These variables have language scope globals or file statics that are allocated in memory before main() starts. Global variables in `C` are treated much differently than `C++`. This difference is because of the complex rules for linking.  
+The compiler generates metadata for any variable in the `.data` or `.bss` sections. These variables have language scope of global or file static. They are allocated in memory before main() starts. Global variables in `C` are treated much differently than `C++`. This difference is because of the complex rules for linking.  
 
 In `C`, a global variable can be declared in several source files and each definition can have different types. The compiler can't see all the possible definitions. The linker will see all the different definitions. The linker defaults to selecting the largest size of all the different declarations.
 
 In `C++`, a global is allocated by the compiler. There can only be one definition so the size of each definition is known at compile time.
 
-Examples sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).
-
 ## Example - globals in 'C' with multiple type definitions
 
 ```cpp
@@ -53,6 +51,8 @@ From a **Developer Command Prompt**:
 
 ## Example - simple function level static
 
+Example sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).
+
 ```cpp
 #include <string.h>
 
@@ -85,6 +85,8 @@ From a **Developer Command Prompt**:
 
 ## Example - all global scopes in C++
 
+Example sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).
+
 ```cpp
 // Run 4 different ways with the choice of one of these flags:
 //

docs/sanitizers/examples-global-overflow.md

@@ -12,7 +12,7 @@ This functionality requires code generation that is activated under an extra com
 
 Consider the [Clang summary](https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterReturn) of the algorithm supporting use after return, and the larger performance costs.
 
-**Warning**: If you create an object file using the extra flag /fsanitize-address-use-after-return the code, generated by the compiler, will make a runtime decision on how to allocate a stack frame.  If the environment variable ASAN_OPTIONS is **not** set to detect_stack_use_after_return, the code is still slower than **only** using /fsanitize=address. There's additional overhead from some stack frames allocating a frame using alloca() instead of putting the frame in the heap. It's best to delete these object files when you are finished processing use-after-return errors.
+**Warning**: If you create an object file using the extra flag `-fsanitize-address-use-after-return`, the code generated by the compiler, will make a runtime decision about how to allocate a stack frame.  If the environment variable ASAN_OPTIONS is **not** set to detect_stack_use_after_return errors, the code is still slower than **only** using `/fsanitize=address`. It's slower because there's still additional overhead from some stack frames allocating space for parts of a frame using alloca(). It's best to delete these object files when you are finished processing use-after-return errors.
 
 Examples sourced from [LLVM compiler-rt test suite](https://github.com/llvm/llvm-project/tree/main/compiler-rt/test/asan/TestCases).