[__s]

https://en.wikipedia.org/wiki/Memory_safety

Outside of your simple example C code, there exists C code which can only be memory safe if the compiler implements a heavy runtime: track pointer allocations, track where pointers source from, raise an error when the pointer is used in an undefined context. See how much work valgrind does to achieve a subset of this task

You could consider C code safe if you included a machine verifiable proof of memory safety with the code.. but that's ridiculously more effort than using Rust

In short, you're arguing semantics over the use of the word safe/unsafe when there's a clear definition Rust offers. You can argue that safe code still has bugs, but that's beside the point

[robalni]

That wiki article seems to define memory-safe code as not containing an arbitrary list of bugs. This doesn't really make sense because even if you have code that doesn't contain those bugs, and even if you have a compiler that helps you to find those bugs, programming is always unsafe. You are not safe just because you don't use the "unsafe" keyword in Rust.

[adgjlsfhk1]

The list isn't arbitrary. Bugs that let you read and write different memory than you meant to are some of the easiest to exploit. If you look back at the type of bugs that make headlines, they're pretty much all memory safety issues or code injection (and the memory issues show up more often).