From the table:

> null pointer dereference ... [C] none; [Zig] runtime; [Rust] runtime

Assuming this is talking normal "safe" Rust, I think I disagree with this. The Rust analogue of a pointer in safe code is a reference, not a Rust pointer, and these can't null at all. You could use an Option<> of a reference, and Rust will internally use null to represent the None (empty) case, but an attept to use the option without checking for None will result in an error at compile time, not runtime. Yes you could convert that into a runtime error, but if it was an error condition for that variable to be None then (depending on the context) you could choose not to use an Option at all and then it would be a compile-time error at the call site to attempt to put None into it.

I don't think I understand what is meant by "type confusion". Surely this would also cause compile-time errors? Even C++ would give compile time errors for this unless you use a cast! (C, unlike C++, lets you implicitly convert from void* to any other pointer type so you don't need a cast to get pointer confusion.) Could someone think of an example of what might be meant here, and how it would cause a runtime error?

I think it's fairly common in rust code to abuse unwrap and such behaving exactly like an unchecked access to a nullable type.

That's the opposite of true. Unwrap is heavily discouraged. I know for Result there is `?` operator, but I don't remember if that worked on Option.

Two random Rust projects:

https://github.com/tokio-rs/tokio:

  $ grep -irn 'unwrap' | wc -l
  1398

  $ grep -irn 'unwrap' | wc -l
  2050