← ClaudeAtlas

rust-unsafe-soundnesslisted

Reason rigorously about whether unsafe Rust is sound — derive and document safety preconditions, tell encapsulated vs exposed unsafe apart, spot "crying wolf" unsafe markers, and use MaybeUninit for uninitialized/partially-initialized memory. Use when auditing an unsafe function for soundness, writing a
takurot/rust-skills-comprehensive · ★ 0 · AI & Automation · score 71
Install: claude install-skill takurot/rust-skills-comprehensive
# Rust Unsafe Soundness `rust-unsafe-fundamentals` covers how to write everyday unsafe correctly. This skill is for the harder, rarer job: **proving** an unsafe function is sound for every possible input, not just the inputs you tested — the difference between "it worked when I ran it" and "it cannot be misused into UB." ## Soundness — the actual definition > A function is **sound** if it cannot trigger undefined behavior for *any* input that > satisfies its documented safety preconditions. The critical, easy-to-miss part: soundness is a claim about **all possible inputs the type system allows**, not about the inputs your tests happen to exercise. A function can pass every test you write and still be unsound, if there exists *some* other legal-looking call that triggers UB. This is why "it works" is not evidence of soundness — you need to reason about the full space of legal calls, not a sample of them. The precondition-satisfying side of the contract is the **caller's** job (the human writing the call site, since the compiler doesn't check preconditions); making sure the function *behaves* when preconditions are satisfied is the **implementer's** job. A sound function holds up its end regardless of what the compiler does or doesn't check. ## Three shapes of a function with unsafe inside it — know which one you're looking at The same "copy bytes from source to dest" logic, in three shapes with very different soundness properties: **1. Encapsulated unsafe (safe functio