flawopen.com/Memory Safety/Rust unsafe
No — that is the entire point of the keyword. Inside unsafe, the compiler stops verifying memory safety and you take responsibility for it. The consequence people underestimate is that unsound unsafe code makes safe code vulnerable: callers who never write the keyword can still trigger memory corruption.
// Trusting a value that SAFE code // is allowed to get wrong pub fn fill(&mut self, iter: impl Iterator<Item=u8>) { let (lower, _) = iter.size_hint(); self.reserve(lower); unsafe { let p = self.as_mut_ptr(); for (i, x) in iter.enumerate() { // writes past the allocation // if the hint understated ptr::write(p.add(i), x); } } } // size_hint is a SAFE method. Any // safe caller may return a wrong // lower bound — so this API is // unsound, not merely risky.
pub fn fill(&mut self, iter: impl Iterator<Item=u8>) {
for x in iter {
// capacity re-checked per item;
// no value from safe code
// determines a memory bound
self.reserve(1);
unsafe {
let p = self.as_mut_ptr()
.add(self.len);
ptr::write(p, x);
}
self.len += 1;
}
}
// SAFETY: p points into an allocation
// with capacity for at least one more
// element, guaranteed by reserve(1).The claim worth stating precisely is: safe Rust cannot cause undefined behaviour, provided every unsafe block it depends on is sound. That is a conditional guarantee, and the condition is discharged by humans, not the compiler.
This is still an enormous practical improvement over C or C++. In those languages a memory-safety bug can originate anywhere in the program; in Rust it can only originate inside unsafe, which is usually a very small, explicitly marked fraction of a codebase. The auditable surface shrinks from "everything" to "these forty lines". But small is not zero, and a soundness bug inside that surface is exploitable exactly like its C equivalent — CVE-2021-25900 in smallvec was rated CVSS 9.8.
An API is unsound if any possible safe code can trigger undefined behaviour through it. Note the quantifier: it is not "if reasonable code misuses it" but "if any code can". When writing unsafe, assume safe callers are adversarial — a size_hint that lies, a Deref that returns a different value each call, an Ord implementation that is not a total order, a Clone that panics halfway.
The corollary is that unsafe is not locally contained. An unsound block poisons every safe API built on top of it, which is why these are library bugs rather than caller errors.
// SAFETY: comment stating what must hold and why it does. Unexplained unsafe is unreviewable unsafe.cargo audit against the RustSec database, and cargo geiger to see where unsafe is concentrated. Most unsafe in a typical project is in crates you did not write.#![forbid(unsafe_code)] works well for application crates and is worth adopting. It does not extend to dependencies, and some unsafe is unavoidable somewhere — FFI, and the standard library itself, are built on it.
Yes — unsafe trait. Implementing one is an explicit promise carrying safety obligations, which unsafe code may then rely on. The standard library's TrustedLen exists for precisely this iterator-length problem, though it remains unstable.
No. It refines it. The accurate claim is a dramatically smaller and explicitly located attack surface, not the absence of one — and that is still a decisive advantage over languages where every line is a candidate.