Memory safety means avoiding invalid uses of memory. For a C or C++ application, moving a critical component to Rust can turn some memory bugs—such as dangling pointers and data races—from dangerous runtime failures into compile-time errors. This can be done one component at a time rather than through a full rewrite. section 1.4.2 section 1.6
Ownership is central to those checks. One handle controls when a piece of memory is allocated and deallocated; Rust requires code to follow its ownership rules. The compiler can then reject many bugs that a C or C++ programmer would otherwise have to prevent by tracking ownership manually. section 1.4.2
A dangling-pointer risk
Suppose a component might keep using a pointer after the memory it refers to has been freed. That is the kind of bug safe Rust is designed to reject at compile time. When the component must use memory managed by non-Rust code, however, the compiler cannot verify how that memory was allocated, accessed, or freed. An unsafe block puts responsibility for upholding Rust’s safety rules on the developer. section 1.4.2 section 3.1
Treat safety as a goal to verify throughout an incremental refactor:
- Choose the parts of an existing C or C++ application where better memory safety matters, and decide how they will communicate with Rust. section 1.6
- Mirror the existing behavior in Rust and integrate it with the application. section 1.6
- Test the new functionality and compare results from the old and new code paths before rollout. section 1.6
