Rust in an Instant

Yes, of course.

Calling platform functions are always unsafe. In the case of malloc, the standard library wraps calls using a safe interface. This assumes that malloc is implemented to spec because there's no good way to handle it otherwise.

The unsafe beast hides in unexpected places. That being said this one is not too bad in my opinion, it's fairly unlikely to occur accidentally (if you use no_mangle you're probably dealing with unsafe interfaces anyway) and it doesn't really invalidate any of Rust's core principles and models, it's more like a plumbing issue in the linker.

It would be nice if these programs failed to link however.

Yes, and not only no_mangle, but anything that has to do with linking in general can make safe Rust programs unsound (e.g. use LD_PRELOAD to change the malloc implementation at run-time with dynamic linking, and put in a broken/buggt malloc implementation instead).

The TL;DR is that safe Rust is only sound, if the safe APIs it uses are sound, which requires their implementations to be sound (Derek Dreyer et al. [0]). That is, the soundness proofs a Rust's compiler gives you only apply to Rust programs with sound unsafe code.

If you exchange the malloc implementation with an unsound one, then the soundness proofs the compiler provides just don't apply to your program anymore (they apply only to programs with a sound malloc implementation).

---

Being able to worry about soundness in this space is kind of a luxus problem, but probably still one the most interesting aspect of Rust. Like, with C or C++, there is little discussion about soundness because most of the language is already unsound. Like, not even MISRA C tries to make a subset of C sound, just "less dangerous" or "less likely to make mistakes".

The big deal of Rust is that it modularizes soundness proofs, allowing users to prove different modules of their program "conditionally sound", e.g., sound _if_ everything they use is also sound. Most Rust code on crates.io is close to 100% safe Rust code, and that code is already "conditionally sound". This means that you only need to manually prove the remaining 1% of the unsafe Rust code correct, which is a much more tractable problem, than trying to prove 100% of the code correct.

This allows people to refactor that 1% of the code into tiny modules, that each can be proven correct in isolation, and that allow changes to be more precisely scrutinized.

The impact of this is huge. You can refactor pretty much all code you write without worrying about soundness, only needing to worry about it if you need to change one of those tiny modules.

[0] http://plv.mpi-sws.org/rustbelt/

Heh, was gonna link that bug :) But there's an even simpler way: open /proc/self/mem in read-write mode.

"Rust is safe" means something like, if you write code to do a thing, it doesn't unintentionally lead to memory corruption. Opening /proc/self/mem is being fairly intentional about it. Colliding with a C function in another library could be unintentional, which is why I opened that, but most of the time (as with the blog post) it's fairly deliberate and obvious.

Or: "Rust user discovers the linker"

I remember reading it was everyone's favorite weekend language. There's certainly more people using it over the weekend than using it professionally. Maybe that's why there's so much of here today.