4 ms·

Rust is safe in terms of memory usage and race conditions, nobody claims that Rust compiler will catch all 100% of bugs human can invent.

sidlls 10y ago
Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.
- steveklabnik 10y ago
  If Rust is not memory safe in safe code, then you've found a bug. Please report it to https://www.rust-lang.org/security.html https://www.rust-lang.org/security.html
  - sidlls 10y ago
    Let me clarify: in Rust it is trivial to use memory unsafely. It is not, so far as I have found, trivial to hide that fact because it is required to use "unsafe" syntax decoration" to do so.
    - Manishearth 10y ago
      The issue here is that that definition of "safe" language basically excludes all practical languages, including languages like Python, because FFI is possible. In general when talking about safety in a language it's about the level of explicitness required to trigger unsafety. I like the distinction made in the nomicon (https://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsaf...) -- Rust comprises of two distinct languages. You have everyday Rust, which is completely memory safe, and "unsafe Rust", which looks similar to everyday Rust but is not safe. `unsafe {}` blocks are your FFI between the two. Looking at unsafe blocks as FFI is IMO a very useful mental model especially for understanding the changes to invariants involved.
  - derefr 10y ago
    If you're relying on any random third-party Rust crates you haven't audited yourself, don't you lose the safety guarantee? A given crate might turn out to have implemented operations on some data-structure using unsafe blocks, and then to have failed to mark its own API functions as unsafe in turn (like the Rust stdlib does, but without the "extensive manual auditing" that the stdlib gets). AFAIK, cargo doesn't have any feature to point out when a crate contains unsafe code—so you pretty much need to grep the source of every crate you consume for "unsafe".
    - steveklabnik 10y ago
      That's why I said "safe code," I mean, not using any unsafe. The issue you're talking about is related, but different.
      - derefr 10y ago
        Right, I was just trying to put a finer point on your use of "using any unsafe" here. It sounds like you mean "using" in the lexical sense (writing the token "unsafe" in your code), but you mean it in the dynamic sense (having an unsafe block in your control flow graph.)
        steveklabnik 10y ago
        That's a good distinction to draw, thanks.
    - Animats 10y ago
      There's a lot more unsafe code in Rust crates than there should be. That's a fixable problem. Some stuff from the early days predates the optimizer getting smart enough that unsafe code isn't needed. I wrote on this a few days ago in a Rust topic.
      - Manishearth 10y ago
        While I now mostly agree with you that there is more unsafe code than there should be, I still maintain that the frequency of unsafe in a deptree is usually still small enough to be practically auditable, ignoring FFI. It could/should be much less, but it's not too bad. I've done such audits a few times and it's not been too hard and taken very little time. Auditing FFI is a whole other challenge, however :(
- staticassertion 10y ago
  In safe rust it is definitely not trivial to overflow a buffer in a way that violates memory safety.

sidlls 10y ago

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

steveklabnik 10y ago
If Rust is not memory safe in safe code, then you've found a bug. Please report it to https://www.rust-lang.org/security.html https://www.rust-lang.org/security.html
- sidlls 10y ago
  Let me clarify: in Rust it is trivial to use memory unsafely. It is not, so far as I have found, trivial to hide that fact because it is required to use "unsafe" syntax decoration" to do so.
  - Manishearth 10y ago
    The issue here is that that definition of "safe" language basically excludes all practical languages, including languages like Python, because FFI is possible. In general when talking about safety in a language it's about the level of explicitness required to trigger unsafety. I like the distinction made in the nomicon (https://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsaf...) -- Rust comprises of two distinct languages. You have everyday Rust, which is completely memory safe, and "unsafe Rust", which looks similar to everyday Rust but is not safe. `unsafe {}` blocks are your FFI between the two. Looking at unsafe blocks as FFI is IMO a very useful mental model especially for understanding the changes to invariants involved.
- derefr 10y ago
  If you're relying on any random third-party Rust crates you haven't audited yourself, don't you lose the safety guarantee? A given crate might turn out to have implemented operations on some data-structure using unsafe blocks, and then to have failed to mark its own API functions as unsafe in turn (like the Rust stdlib does, but without the "extensive manual auditing" that the stdlib gets). AFAIK, cargo doesn't have any feature to point out when a crate contains unsafe code—so you pretty much need to grep the source of every crate you consume for "unsafe".
  - steveklabnik 10y ago
    That's why I said "safe code," I mean, not using any unsafe. The issue you're talking about is related, but different.
    - derefr 10y ago
      Right, I was just trying to put a finer point on your use of "using any unsafe" here. It sounds like you mean "using" in the lexical sense (writing the token "unsafe" in your code), but you mean it in the dynamic sense (having an unsafe block in your control flow graph.)
      - steveklabnik 10y ago
        That's a good distinction to draw, thanks.
  - Animats 10y ago
    There's a lot more unsafe code in Rust crates than there should be. That's a fixable problem. Some stuff from the early days predates the optimizer getting smart enough that unsafe code isn't needed. I wrote on this a few days ago in a Rust topic.
    - Manishearth 10y ago
      While I now mostly agree with you that there is more unsafe code than there should be, I still maintain that the frequency of unsafe in a deptree is usually still small enough to be practically auditable, ignoring FFI. It could/should be much less, but it's not too bad. I've done such audits a few times and it's not been too hard and taken very little time. Auditing FFI is a whole other challenge, however :(
staticassertion 10y ago
In safe rust it is definitely not trivial to overflow a buffer in a way that violates memory safety.