[bluejekyll]

What kind of crash? Rust's memory model guarantees memory safety, meaning you can not have: use after free; double free; buffer overflows; index out-of-bound issues; etc.

What it doesn't prevent is crashes. Rust programs will crash if your program tries to do any of the above, and-or blindly unwrap() Result or Option types.

Now Rust can segfault, etc., just like Java, Node, Go, Ruby, Python, PHP and every other "memory-safe" language when using unsafe or native extensions.

[collyw]

I think it was an index out of bounds type error. Can't quite remember.

To be clear, it was my inexperience with Rust, rather than a the language that was the problem. I found it amusing when I had read a few comments saying that "if it compiles it will run".

[vertex-four]

The person you were replying to said it will run without certain types of errors, not "it will run".

[steveklabnik]

Yes, that would be a panic.

[rmc]

> index out-of-bound issues

You sure about that? You can still get Rust to panic if you try to index a vec past the end...

[steveklabnik]

A panic is significantly different than an actual out of bound access; the latter is the cause of a lot of issues, but a panic is preventing those issues.

[rmc]

Ah I get you! You can't read past the end of an array, but you can get an error.

[steveklabnik]

Exactly!

[dronemallone]

So isn't the memory model more to do with the compiler or operating system rather than the programming language? Do think it's possible to write a C compiler that checks for use after free, double free, buffer overflows, index out-of-bound issues, etc.?

Surely if one programming language can do it, another can?

[Manishearth]

A C compiler that checks for all of these things at runtime is Valgrind. It's used when testing.

A C compiler that checks all of these things at compile time would no longer be a C compiler.

Compile time guarantees require you to change the language and restrict what is allowed to compile. Rust does just that, it's a different language. You could write an extension to C like Cyclone (or the ISOCPPCore guidelines for C++) that make it safer via compile time checks. You would likely need more annotations and most existing C programs would no longer compile.

(There is the ergonomic benefit of being able to transition from a C codebase to a, say, Cyclone one, though)

[Others]

It's not possible to write a C compiler that guarantees what Rust guarantees. There are just too many implicit assumptions about pointers. Even if you check most cases, weird stuff like XOR linked lists will trip you up. (And sure, if you changed the language you could make it safe -- but then it wouldn't be C anymore.)

[pjmlp]

> Do think it's possible to write a C compiler that checks for use after free, double free, buffer overflows, index out-of-bound issues, etc.?

No, due to the way the language semantics works.

There are static analyzers that do something like that, MISRA-C, High Integrity C, Frama-C, but you are literally using C with Ada semantics at that point, thus it is almost like another language.

[bluejekyll]

Of course, and many programming languages offer similar features as Rust. I've not used Ada myself, but people claim it offers similar safety features.

From my experience though, Rust is the first language that I've had the pleasure to use which offers both the safety guarantees of Java (and more, no data races!) and the low level features of C.

It still leaves me in awe what has been accomplished with Rust, and I've been using it for more than two years now.

[openasocket]

For arbitrary C code, I believe checking for those issues is equivalent to the halting problem. Or at least uncomputable.