Rust Sharing Object

Signed-off-by: Vineel Kovvuri <[email protected]>

content/blog/Rust-Sharing-Objects/index.md

@@ -100,7 +100,7 @@ let mut b_ptr = &mut b as *mut B as *mut c_void;
 The distinction lies in how the Rust borrow checker analyzes the lifetimes
 and mutability of references during compilation. Let's break this down:
 
-#### Why Part 1 Works:
+#### Why Part 1 Works?
 1. Order of Operations:
     - `a` is created with a mutable reference to `c`.
     - `a_ptr` is cast to a `*mut c_void`. At this point, the borrow checker no
@@ -109,20 +109,20 @@ and mutability of references during compilation. Let's break this down:
     - Finally, `b_ptr` is cast to a `*mut c_void`.
 
 2. Temporary Escape from Borrow Checking:
-    - The cast to `*mut c_void` removes the borrow checker’s visibility into
-        how the mutable reference (`mut_ref`) in `A` is being used. Rust assumes
-        you are responsible for managing aliasing and mutability safety when you
-        use raw pointers.
+    - ==The cast to `*mut c_void` removes the borrow checker’s visibility into how
+      the mutable reference (`mut_ref`) in `A` is being used. Rust assumes you
+      are responsible for managing aliasing and mutability safety when you use
+      raw pointers.==
 
 3. Sequential Mutability:
     - Since `a` is converted to `a_ptr` (a raw pointer) before `b` is created,
-        the borrow checker treats the mutable borrow in `a` as no longer active.
+      the borrow checker treats the mutable borrow in `a` as no longer active.
 
-#### Why Part 2 Fails:
+#### Why Part 2 Fails?
 1. Simultaneous Mutable Borrows:
     - In this case, both `A` and `B` are holding mutable references to `c` at
-        the same time. This violates Rust's borrowing rules, which prohibit
-        multiple mutable borrows of the same data simultaneously.
+      the same time. This violates Rust's borrowing rules, which prohibit
+      multiple mutable borrows of the same data simultaneously.
 
 2. Borrow Checker Enforcement:
     - When you write `let mut b = B { mut_ref: &mut c };`, the borrow checker

docs/blog/rust-sharing-objects/index.html

@@ -119,7 +119,7 @@ <h3 id="question-why-part-1-works-but-not-part-2-what-is-so-special-about-mut-c_
 </span></span></span></code></pre></div><h3 id="answerfrom-chatgpt">Answer(From ChatGPT):</h3>
 <p>The distinction lies in how the Rust borrow checker analyzes the lifetimes
 and mutability of references during compilation. Let&rsquo;s break this down:</p>
-<h4 id="why-part-1-works">Why Part 1 Works:</h4>
+<h4 id="why-part-1-works">Why Part 1 Works?</h4>
 <ol>
 <li>
 <p>Order of Operations:</p>
@@ -134,10 +134,10 @@ <h4 id="why-part-1-works">Why Part 1 Works:</h4>
 <li>
 <p>Temporary Escape from Borrow Checking:</p>
 <ul>
-<li>The cast to <code>*mut c_void</code> removes the borrow checker’s visibility into
-how the mutable reference (<code>mut_ref</code>) in <code>A</code> is being used. Rust assumes
-you are responsible for managing aliasing and mutability safety when you
-use raw pointers.</li>
+<li><mark>The cast to <code>*mut c_void</code> removes the borrow checker’s visibility into how
+the mutable reference (<code>mut_ref</code>) in <code>A</code> is being used. Rust assumes you
+are responsible for managing aliasing and mutability safety when you use
+raw pointers.</mark></li>
 </ul>
 </li>
 <li>
@@ -148,7 +148,7 @@ <h4 id="why-part-1-works">Why Part 1 Works:</h4>
 </ul>
 </li>
 </ol>
-<h4 id="why-part-2-fails">Why Part 2 Fails:</h4>
+<h4 id="why-part-2-fails">Why Part 2 Fails?</h4>
 <ol>
 <li>
 <p>Simultaneous Mutable Borrows:</p>

hugo.yaml

@@ -51,4 +51,17 @@ markup:
   goldmark:
     renderer:
       unsafe: true
+    extensions:
+          extras:
+            delete:
+              enable: true
+            insert:
+              enable: true
+            mark:
+              enable: true
+            subscript:
+              enable: true
+            superscript:
+              enable: true
+          strikethrough: false
 enableEmoji: true