I don't think Rust really makes NULL dereferences any better. In practice, a NULL dereference in C is almost always "just" a crash that can't be turned into something worse (unlike the rest of these kinds of bugs), and Rust makes it really easy to call "unwrap", which if your Option is None... crashes.
back
2 comments
Explicit `unwrap` (rust) is really orders of magnitude better than implicit `unwrap` (c dereference if you're lucky and the compiler hasn't optimized based on the assumption that the pointer is non-null). There aren't actually many explicit unwrap's in practical code, and they're something you notice when auditing or reviewing the code. The change in type means both the caller and the callee almost always agree on whether or not the contract is that "this pointer can be null" or "this pointer isn't null".
> In practice, a NULL dereference in C is almost always "just" a crash that can't be turned into something worse
No, in C a NULL pointer dereference is not a crash, it's undefined behavior (which yes, can manifest as a crash), which is much more unpredictable.
Indeed.
For anyone still believing a NULL dereference (or any of the other UB that is in the C spec) is just a segfault, "What Every C Programmer Should Know About Undefined Behavior" is still required reading:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Here's how triggering UB ends up as a vulnerability:
> Here's how triggering UB ends up as a vulnerability
To be fair, dereferencing NULL ended up as a vulnerability due to
1. the optimiser removing the subsequent NULL check, and
2. the zero page being mapped.
While 1. may happen, depending on how sophisticated the compiler is, 2. was already a security issue and is 'almost always' not the case.