There are memory safety bugs that won't cause a segmentation fault or create a buffer overflow exploit, but result in logical errors. For example: void inn

There are memory safety bugs that won't cause a segmentation fault or create a buffer overflow exploit, but result in logical errors. For example: void inner (const T& t1, T& t2); void outer (T* t, int i, int j) { inner(t[i], t[j]); } There are three memory safety bugs in that code: - the pointer `t` is not checked for null - the indices `i` and `j` are not checked to see if they are outside the bounds of `i` and `j` - the indices `i` and `j` are not checked to see if they are the same. The first bug will cause a segfault and crash. The second is a potential buffer exploit. The third is a logical bug that can be exploited depending on what inner() is supposed to do. Most people know to check the first two, the third one is subtle and isn't necessarily a bug. But it may become a bug that can be exploited inside `inner`, especially over the lifetime of the code. Rust will prevent all three, or force you to perform the checks before using an `unsafe` block. But more than that, this kind of issue crops up due to an inherent weakness of code review - it catches errors in blocks of logic, but not in logic below it and logic above it. Since C/C++ don't have idiomatic error handling worth a damn (the only "idiomatic" errors in C++ are debug assertions, ime) you can't defend against silent logic bugs due to violating invariants of callers or callees that are expressed through Option/Result types in Rust (I mentioned this in a comment above). That's the real benefit of writing code in Rust, in addition to the absence of footguns.