Update posts/2025-01-09-Rust-1.84.0.md

Co-authored-by: Travis Cross <[email protected]>

posts/2025-01-09-Rust-1.84.0.md

@@ -76,17 +76,16 @@ and the [stabilization report](https://github.com/rust-lang/rust/pull/130654)
 
 ### Strict provenance APIs
 
-In Rust, [pointers are not simply an “integer” or
-“address”](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html). For
-instance, it’s uncontroversial to say that a Use After Free is clearly
-Undefined Behavior, even if you “get lucky” and the freed memory gets
-reallocated before your read/write. It is also uncontroversial that writing
-through a pointer derived from an `&i32` reference is Undefined Behavior, even
+In Rust, [pointers are not simply an "integer" or
+"address"](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html). For
+instance, a "use after free" is undefined behavior even if you "get lucky" and the freed memory gets
+reallocated before your read/write. As another example, writing
+through a pointer derived from an `&i32` reference is undefined behavior, even
 if writing to the same address via a different pointer is legal. The underlying
 pattern here is that *the way a pointer is computed matters*, not just the
 address that results from this computation. For this reason, we say that
-pointers have **provenance**: to fully characterize pointer-related Undefined
-Behavior in Rust, we have to know not only the address the pointer points to,
+pointers have **provenance**: to fully characterize pointer-related undefined
+behavior in Rust, we have to know not only the address the pointer points to,
 but also track which other pointer(s) it is "derived from".
 
 Most of the time, programmers do not need to worry much about provenance, and