Anyone who has programmed in Rust has at one point or another “fought the Borrow Checker” 1 . You write code that appears to be (and possibly is)

Burning the Midnight Coffee

submited by
Style Pass
2024-11-17 22:00:04

Anyone who has programmed in Rust has at one point or another “fought the Borrow Checker” 1 . You write code that appears to be (and possibly is) completely fine but the compiler is unable to statically 2 prove that it is memory safe, so it screams at you.

You may have any number of immutable borrows to the same data, or a single mutable borrow to that data. 1 writer xor N readers.

But what’s a “borrow”? What’s an “owner”? Why those two rules? Is Rule 2 necessary if we don’t care about multithreading?

I’m not going to explain the rust borrow checker. You can read the Rust documentation if you want a very detailed explanation. Rather, the goal of this post is to naturally arrive at a similar solution by tackling the same problem: memory safety through compile-time checks.

There are two main vulnerabilities we’re trying to prevent: Double-Free (alongside memory leaks) and Use-After-Free. The nastiest vulnerability, Out-of-Bounds Access, is trivial to prevent with minimal runtime support 3 .

Leave a Comment