safe-over-unsafe

To design a safe Rust API over unsafe code, encapsulate unsafe operations in private fields and expose public methods that enforce invariants and panic safety. This abstraction prevents undefined behavior by ensuring all inputs and states remain valid.

Wrapping raw Rust pointers and MaybeUninit requires creating new types that guarantee initialization and aliasing rules before public exposure. You enforce these memory safety invariants via compile-time checks to prevent undefined behavior.

Soundness review in Rust unsafe code is the process of verifying that public APIs cannot trigger undefined behavior regardless of user input. It involves checking raw pointer validity, enforcing invariants, and ensuring panic safety to maintain memory safety guarantees.

Building a safe Rust interface for C code via FFI involves wrapping the raw FFI calls in a safe Rust abstraction. You manage raw pointers and enforce memory safety invariants privately, preventing undefined behavior from leaking into the public API.

Manual Send and Sync implementations in Rust are needed when creating custom types backed by raw pointers or FFI that cross thread boundaries. You must verify thread safety invariants manually because the compiler cannot automatically prove memory safety for unsafe code.

Abstracting over unsafe Rust code requires rigorously maintaining invariants and panic safety, which can introduce runtime overhead or complexity. Limitations include the constant risk of undefined behavior if internal safety checks fail or if raw pointer validity is misjudged.