4 ms·

Wait, isn’t this a soundness issue? Couldn’t you, say, replace malloc with a safe function that always returned 0x4 [0], causing segfaults with no unsafe? [0]:

• _pmf_ 6y ago
  Yes, of course.
• ChrisSD 6y ago
  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.
  • dragonsh 6y ago
    Another defence for Rust as if all the problem is with C, Rust will magically make everything safe (however unreadable and not really true). This is another form of marketing Rust, in itself Rust has a steep learning curve and not developer friendly so require constant barrage of hype. It relies on C++ based LLVM for generating binaries like many other languages and underlying unsafe C library for doing anything useful. It cannot yet be used extensively in Firefox for what it was designed, hope it can accomplish its primary goal for building Firefox sooner.
    • ChrisSD 6y ago
      Nowhere in my comment did I mention C, Firefox, learning curves or marketing so I'm unsure what you're replying to. To be clear, this issue isn't about Rust, the language. This is about Rust's standard library creating a safe abstraction around platform functions (although altering `memcmp` et al would affect how certain language features are implemented). And it doesn't matter what language malloc is written in. It could be Python, C, Rust or brainfuck, the issue is the same. Rust's standard library assumes it is implemented to spec. I'm not sure that it could or should do otherwise.
    • gameswithgo 6y ago
      Any language is going to have to rely on some unsafe foundations to do anything useful. That isn't a meaningful criticism. If you build a 100,000 line code base, would you rather that all of it could potentially have data races and buffer overruns, or that only malloc and some syscalls can? Rust is absolutely not easy as you say, but neither is C or C++.
      • MinelloGiacomo 6y ago
        Totally agree, it's about managing risk!
      • whatshisface 6y ago
        C is easy to do wrong and hard to do right, Rust is hard to do wrong and about average to do right.
        • a1369209993 6y ago
          There has never been, nor will there ever be, any language in which it is the least bit difficult to write bad code; the difference is that Rust provides better ability to notice that you've done it wrong.
    • steveklabnik 6y ago
      > It cannot yet be used extensively in Firefox for what it was designed, What do you mean by this?
    • lioeters 6y ago
      > It cannot yet be used extensively in Firefox for what it was designed Here's an extensive list of Rust components within Firefox - shipped, in progress, and proposed: https://wiki.mozilla.org/Oxidation#Shipped https://wiki.mozilla.org/Oxidation#Shipped
• simias 6y ago
  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.
• fluffything 6y ago
  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/ http://plv.mpi-sws.org/rustbelt/
• geofft 6y ago
  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.