3 ms·

Not an inherently bad thing, really. The unsafe keyword has two meanings: 1. An unsafe block tells the compiler "trust me, I know this is unsafe and I know how

Not an inherently bad thing, really. The unsafe keyword has two meanings: 1. An unsafe block tells the compiler "trust me, I know this is unsafe and I know how to do it safely" 2. An unsafe function tells the compiler "this is unsafe! it needs to be put inside another unsafe function or an unsafe block" So an unsafe block essentially terminates an unsafe call chain. There are a bunch of things which are inherently marked as unsafe in Rust, usually because the compiler can't reason about them, like dereferencing a raw pointer as opposed to a borrow-checked Rust reference. That's what calls for an unsafe function in the case of strlen -- to only iterate over the string once we just have to assume that the pointer points to valid memory and is null-terminated, so like a lot of things in C, we just cross our fingers and go for it. The fact that Rust knows this could fail miserably is why it needs to have an unsafe block.

xienze 10y ago
> 1. An unsafe block tells the compiler "trust me, I know this is unsafe and I know how to do it safely" Right, so aren't you giving up the biggest advantage of Rust, that your code will be safe by virtue of it getting through the Rust compiler's safety checking?
- dikaiosune 10y ago
  Yes, although there are other advantages to using Rust (about halfway down there's a "What does Rust offer here?" section that discusses in more detail). Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety. Also, if I were taking this more seriously, the wildly unsafe Rust code would just be a beach head for a bottom-up conversion of a project. You have a project which uses strlen? Great, now use this Rust version. Now incrementally rewrite the strlen-using code in Rust. Now change strlen to use a Rust CString...and so on. Each time you identify a new module boundary, rewrite its dependencies in Rust, and then consume the module while preserving it's outward facing interfaces.
  - xienze 10y ago
    > Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety. That's kind of what I'm getting at. If cstdlib is inherently unsafe, and Rust cstdlib is going to be inherently unsafe, what's the point? Because of some other Rust advantages things may end up safer, but there's a lot to be said for years/decades worth of fixing existing cstdlib implementations such that you can be reasonably sure that most of what's in there is as safe as it's going to get.
    - steveklabnik 10y ago
      > what's the point? This is directly discussed in the post, under the "What does Rust offer here?" section.
    - dbaupp 10y ago
      The interface will have to be `unsafe`, yes (that is, there are conditions that the code calling the functions must satisfy to avoid memory unsafety), but the internals can control this unsafety and avoid having more: libc's have vulnerabilities that are not caused by their inherently unsafe interface. The power of Rust is the ability to package up `unsafe`ty behind safe interfaces without adding unnecessary cost, so that most users don't have to be super-careful about avoiding memory corruption. This still works at a low-level like in the implementation of a libc or an operating system[1]. Also, Rust is a more expressive language, which helps avoid bugs (e.g. enums/discriminated unions means the programmer can't accidentally access invalid state), allows writing shared algorithms and data structures efficiently once instead of needing to do the bug-prone task of reimplementing (or taking a performance/safety hit with void*), and, subjectively, may be nicer to read/write . [1]: http://os.phil-opp.com/modifying-page-tables.html http://os.phil-opp.com/modifying-page-tables.html
    - sitkack 10y ago
      Security and safety isn't a binary relation, it is a continuum. I think what you are experiencing is a transitive-covering fallacy. The safeties with which you are speaking aren't the same type or the same units. The argument you making is often made by people on security discussion lists to _prove_ that modifying X to make it more secure is pointless because there is still a small possibility of Y. > years/decades How long has MUSL been in development? How many programmers there are in the world?
Retra 10y ago
Your #1 should really say "I know this is safe, but since the compiler can't prove it, you'll have to trust me." That is, using unsafe doesn't mean you're doing anything unsafe, only that the rust compiler doesn't model why it is safe.

xienze 10y ago

> 1. An unsafe block tells the compiler "trust me, I know this is unsafe and I know how to do it safely" Right, so aren't you giving up the biggest advantage of Rust, that your code will be safe by virtue of it getting through the Rust compiler's safety checking?

dikaiosune 10y ago
Yes, although there are other advantages to using Rust (about halfway down there's a "What does Rust offer here?" section that discusses in more detail). Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety. Also, if I were taking this more seriously, the wildly unsafe Rust code would just be a beach head for a bottom-up conversion of a project. You have a project which uses strlen? Great, now use this Rust version. Now incrementally rewrite the strlen-using code in Rust. Now change strlen to use a Rust CString...and so on. Each time you identify a new module boundary, rewrite its dependencies in Rust, and then consume the module while preserving it's outward facing interfaces.
- xienze 10y ago
  > Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety. That's kind of what I'm getting at. If cstdlib is inherently unsafe, and Rust cstdlib is going to be inherently unsafe, what's the point? Because of some other Rust advantages things may end up safer, but there's a lot to be said for years/decades worth of fixing existing cstdlib implementations such that you can be reasonably sure that most of what's in there is as safe as it's going to get.
  - steveklabnik 10y ago
    > what's the point? This is directly discussed in the post, under the "What does Rust offer here?" section.
  - dbaupp 10y ago
    The interface will have to be `unsafe`, yes (that is, there are conditions that the code calling the functions must satisfy to avoid memory unsafety), but the internals can control this unsafety and avoid having more: libc's have vulnerabilities that are not caused by their inherently unsafe interface. The power of Rust is the ability to package up `unsafe`ty behind safe interfaces without adding unnecessary cost, so that most users don't have to be super-careful about avoiding memory corruption. This still works at a low-level like in the implementation of a libc or an operating system[1]. Also, Rust is a more expressive language, which helps avoid bugs (e.g. enums/discriminated unions means the programmer can't accidentally access invalid state), allows writing shared algorithms and data structures efficiently once instead of needing to do the bug-prone task of reimplementing (or taking a performance/safety hit with void*), and, subjectively, may be nicer to read/write . [1]: http://os.phil-opp.com/modifying-page-tables.html http://os.phil-opp.com/modifying-page-tables.html
  - sitkack 10y ago
    Security and safety isn't a binary relation, it is a continuum. I think what you are experiencing is a transitive-covering fallacy. The safeties with which you are speaking aren't the same type or the same units. The argument you making is often made by people on security discussion lists to _prove_ that modifying X to make it more secure is pointless because there is still a small possibility of Y. > years/decades How long has MUSL been in development? How many programmers there are in the world?

Retra 10y ago

Your #1 should really say "I know this is safe, but since the compiler can't prove it, you'll have to trust me." That is, using unsafe doesn't mean you're doing anything unsafe, only that the rust compiler doesn't model why it is safe.