Merge pull request #86 from PierreBhs/fix-c-cpp-book-typos

Fix typos in c-cpp-book markdown files

Author: atulkhare4096

c-cpp-book/src/ch05-data-structures.md

@@ -74,9 +74,9 @@ fn main() {
 
         let d = &mut a;
 
-        /* 
-         * Uncommenting the line below would be cause the 
-         * program to not compile, because `b` is used 
+        /*
+         * Uncommenting the line below would cause the
+         * program to not compile, because `b` is used
          * while the mutable reference `d` is live in the current scope
          * 
          * You cannot have a mutable and immutable reference in use in the same scope

c-cpp-book/src/ch07-ownership-and-borrowing.md

@@ -191,7 +191,7 @@ graph LR
     - User defined data types can optionally opt into ```copy``` semantics using the ```derive``` macro with to automatically implement the ```Copy``` trait
     - The compiler will allocate space for the copy following a new assignment
 ```rust
-// Try commenting this out to see the change in let p1 = p; belw
+// Try commenting this out to see the change in let p1 = p; below
 #[derive(Copy, Clone, Debug)]   // We'll discuss this more later
 struct Point{x: u32, y:u32}
 fn main() {

c-cpp-book/src/ch08-crates-and-modules.md

@@ -97,7 +97,7 @@ cargo new --lib hellolib
 ```
 
 ## Exercise: Using workspaces and package dependencies
-- Take a look at the generated Cargo.toml in ```hello``` and ```hellolib```. Notice that both of them have been to the upper level ```Cargo.toml```
+- Take a look at the generated Cargo.toml in ```hello``` and ```hellolib```. Notice that both of them have been added to the upper level ```Cargo.toml```
 - The presence of ```lib.rs``` in ```hellolib``` implies a library package (see https://doc.rust-lang.org/cargo/reference/cargo-targets.html for customization options)
 - Adding a dependency on ```hellolib``` in ```Cargo.toml``` for ```hello```
 ```toml

c-cpp-book/src/ch09-error-handling.md

@@ -47,7 +47,7 @@ fn main() {
 - Rust ```Option``` can be processed in various ways
     - ```unwrap()``` panics if the ```Option<T>``` is ```None``` and returns ```T``` otherwise and it is the least preferred approach 
     - ```or()``` can be used to return an alternative value 
-    ```if let``` lets us test for ```Some<T>```
+    - ```if let``` lets us test for ```Some<T>```
 
 > **Production patterns**: See [Safe value extraction with unwrap_or](ch17-2-avoiding-unchecked-indexing.md#safe-value-extraction-with-unwrap_or) and [Functional transforms: map, map_err, find_map](ch17-2-avoiding-unchecked-indexing.md#functional-transforms-map-map_err-find_map) for real-world examples from production Rust code.
 ```rust
@@ -151,7 +151,7 @@ fn main() {
 ----
 # Rust error handling
  - Rust errors can be irrecoverable (fatal) or recoverable. Fatal errors result in a ``panic```
-    - In general, situation that result in ```panics``` should be avoided. ```panics``` are caused by bugs in the program, including exceeding index bounds, calling ```unwrap()``` on an ```Option<None>```, etc.
+    - In general, situations that result in ```panics``` should be avoided. ```panics``` are caused by bugs in the program, including exceeding index bounds, calling ```unwrap()``` on an ```Option<None>```, etc.
     - It is OK to have explicit ```panics``` for conditions that should be impossible. The ```panic!``` or ```assert!``` macros can be used for sanity checks
 ```rust
 fn main() {