5 ms·

It’s good to see that at least Miri catches the issues. Hopefully the compiler can catch up with that!

vlovich123 3y ago
Does polonius catch the issue?
throwawaymaths 3y ago
If you need a compiler sidecar anyways, why not just have a simpler language where all the borrow checking is done in a sidecar?
- dralley 3y ago
  You don't "need" a compiler sidecar unless you're specifically writing code to exploit obscure bugs. This is a 0.0001% case
  - throwawaymaths 3y ago
    yeah or if you're using someone else's code that you're trusting doesn't have "obscure bugs" put there to smuggle in a vuln.
    - dralley 3y ago
      Nonetheless, it's far less of an issue than in any other language. You don't need 20 lines of crazy code to slip a serious security vulnerability into C, you can add one with a single character changed half of the time.
      - pcwalton 3y ago
        This is exaggerated re. C, but it is true that the important thing for practical security is whether memory safety is violated in practice, and obscure compiler bugs you have to go out of your way to try to exploit don't affect that. That being said, this bug is pretty bad, and it should be fixed. I should point out that the reason the bug is difficult seems to mainly be because of backwards compatibility concerns. If compatibility weren't an issue, Rust could just ban function contravariance and nobody would care.
        saagarjha 3y ago
        It's not; changing a == to != or a < to <= is very often enough to fully compromise something.
    - muldvarp 3y ago
      If you run somebody else's code and you don't trust that person, you need to read their code carefully anyway. Safe Rust code can do all kinds of shenanigans including: * Wiping your disk * Downloading and running code from the internet * ... Rust's safety guarantees don't exist to protect you from a malicious Rust programmer. They exist to protect you from mistakes a well meaning but fallible Rust programmer can make.
      - throwawaymaths 3y ago
        > Rust's safety guarantees don't exist to protect you from a malicious Rust programmer. This greatly ignores human behavior. A LOT of people who are reviewing rust code are going to only concentrate on unsafe blocks (that's if you're lucky), because rust is advertised as "rust gives you safety", and the word "safety" strongly suggests "don't worry about these things, they are safe". if the advertised safety is a false sense of safety that's a problem.
        muldvarp 3y ago
        Do you have any data backing that argument? I could just as well make the argument that Rust has an extensive "correctness above all else" culture that encourages people to thoroughly review pull requests. Without data both of these claims are just that: claims.
        knose 3y ago
        these people you're talking about would make the same mistake with code written in any language.
- steveklabnik 3y ago
  Miri is fantastic, but also isn't a "compiler sidecar," exactly. It is an interpreter. It's closer to a sanitizer than a compile-time check. It also means a huge, huge overhead to running your code, and in a performance-sensitive language that's a tough sell. It's also only needed for when you dip into unsafe, which is not particularly often, and so imposing this on all code would be the wrong tradeoff.
  - vlovich123 3y ago
    Well libstd has unsafe all over the place. And as OP points out it catches this unsoundness issue in the language even though there's no unsafe anywhere, so it goes beyond just "dip into unsafe".
    - steveklabnik 3y ago
      Sure, but the unsafe in libstd is some of the most tested unsafe in existence. And sure, there are some soundness bugs, but in my experience they are edge cases that rarely come up. I don't think I have personally ever run into one in the wild. Regardless, it is not feasible for you to run your code under miri all the time, so you have to pick and choose where you use it, as a practical matter.
      - vlovich123 3y ago
        Yup, just highlighting that it goes beyond more than just runtime checking for safeness of unsafe code only :)

Does polonius catch the issue?

If you need a compiler sidecar anyways, why not just have a simpler language where all the borrow checking is done in a sidecar?

dralley 3y ago
You don't "need" a compiler sidecar unless you're specifically writing code to exploit obscure bugs. This is a 0.0001% case
- throwawaymaths 3y ago
  yeah or if you're using someone else's code that you're trusting doesn't have "obscure bugs" put there to smuggle in a vuln.
  - dralley 3y ago
    Nonetheless, it's far less of an issue than in any other language. You don't need 20 lines of crazy code to slip a serious security vulnerability into C, you can add one with a single character changed half of the time.
    - pcwalton 3y ago
      This is exaggerated re. C, but it is true that the important thing for practical security is whether memory safety is violated in practice, and obscure compiler bugs you have to go out of your way to try to exploit don't affect that. That being said, this bug is pretty bad, and it should be fixed. I should point out that the reason the bug is difficult seems to mainly be because of backwards compatibility concerns. If compatibility weren't an issue, Rust could just ban function contravariance and nobody would care.
      - saagarjha 3y ago
        It's not; changing a == to != or a < to <= is very often enough to fully compromise something.
  - muldvarp 3y ago
    If you run somebody else's code and you don't trust that person, you need to read their code carefully anyway. Safe Rust code can do all kinds of shenanigans including: * Wiping your disk * Downloading and running code from the internet * ... Rust's safety guarantees don't exist to protect you from a malicious Rust programmer. They exist to protect you from mistakes a well meaning but fallible Rust programmer can make.
    - throwawaymaths 3y ago
      > Rust's safety guarantees don't exist to protect you from a malicious Rust programmer. This greatly ignores human behavior. A LOT of people who are reviewing rust code are going to only concentrate on unsafe blocks (that's if you're lucky), because rust is advertised as "rust gives you safety", and the word "safety" strongly suggests "don't worry about these things, they are safe". if the advertised safety is a false sense of safety that's a problem.
      - muldvarp 3y ago
        Do you have any data backing that argument? I could just as well make the argument that Rust has an extensive "correctness above all else" culture that encourages people to thoroughly review pull requests. Without data both of these claims are just that: claims.
      - knose 3y ago
        these people you're talking about would make the same mistake with code written in any language.
steveklabnik 3y ago
Miri is fantastic, but also isn't a "compiler sidecar," exactly. It is an interpreter. It's closer to a sanitizer than a compile-time check. It also means a huge, huge overhead to running your code, and in a performance-sensitive language that's a tough sell. It's also only needed for when you dip into unsafe, which is not particularly often, and so imposing this on all code would be the wrong tradeoff.
- vlovich123 3y ago
  Well libstd has unsafe all over the place. And as OP points out it catches this unsoundness issue in the language even though there's no unsafe anywhere, so it goes beyond just "dip into unsafe".
  - steveklabnik 3y ago
    Sure, but the unsafe in libstd is some of the most tested unsafe in existence. And sure, there are some soundness bugs, but in my experience they are edge cases that rarely come up. I don't think I have personally ever run into one in the wild. Regardless, it is not feasible for you to run your code under miri all the time, so you have to pick and choose where you use it, as a practical matter.
    - vlovich123 3y ago
      Yup, just highlighting that it goes beyond more than just runtime checking for safeness of unsafe code only :)