3 ms·

Your contrived example makes sense, I guess I'm just confused about how one would have faith that code using `unsafe` is actually safe? As in, to me (an avid no

Your contrived example makes sense, I guess I'm just confused about how one would have faith that code using `unsafe` is actually safe? As in, to me (an avid non-Rust-user), seeing unsafe would mean either A.) I have to audit this codebase to make sure there wasn't any legitimate unsafe behavior, or B.) I just have to totally skip this dependency. If the argument is "You can use unsafe but do things safely", isn't that the same argument as C? "Just have faith that they did it right"?

seoaeu 5y ago
The difference is in the quantity of code you have to audit. In a given Rust project perhaps 0.1% of the lines of code may be unsafe, which while technically non-zero is widly less effort to audit than the entire codebase in the case of something like C
kibwen 5y ago
In addition to what the sibling comment says, you indeed often can find dependencies with no `unsafe` keyword usage whatsoever, and libraries that do so will tout this as a feature. Fortunately for your purposes the broader Rust population (including library authors) is mostly composed of people who are more-or-less skeptical of wanton `unsafe` usage in the first place (as should be self-evident, as otherwise they'd probably just be using C or C++!).
- void_mint 5y ago
  Yeah I suppose I would've been inclined to just throw out any deps that are built atop unsafe. It seems to kind of totally ruin the intended purpose of Rust as a language (to me, who is uninvolved).
  - kibwen 5y ago
    That's perfectly valid, and you would likely benefit from the cargo-geiger tool mentioned above (or just plain-old grep for "unsafe").
  - bsder 5y ago
    "unsafe" doesn't always mean unsafe. For example, you wish to implement a Vector in Rust. You generally don't want to allocate that Vector over and over, so you request more memory than you need. That "extra" memory is uninitialized which is a big no-no in Rust. You might be able to initialize that memory, but that will have performance implications that C/C++ programmers would just laugh at. However, your "invariant" is that you never access that memory until you have a real element that you put there. That's perfectly fine. Nevertheless, accessing that uninitialized area will always be "unsafe" from the Rust compiler point of view.
  - iudqnolq 5y ago
    There has to be some unsafe, or else you can't have the parts of the standard library that interact with the OS. I'd at a minimum also include projects with experienced authors and similar needs such as tokio.

seoaeu 5y ago

The difference is in the quantity of code you have to audit. In a given Rust project perhaps 0.1% of the lines of code may be unsafe, which while technically non-zero is widly less effort to audit than the entire codebase in the case of something like C

kibwen 5y ago

In addition to what the sibling comment says, you indeed often can find dependencies with no `unsafe` keyword usage whatsoever, and libraries that do so will tout this as a feature. Fortunately for your purposes the broader Rust population (including library authors) is mostly composed of people who are more-or-less skeptical of wanton `unsafe` usage in the first place (as should be self-evident, as otherwise they'd probably just be using C or C++!).

void_mint 5y ago
Yeah I suppose I would've been inclined to just throw out any deps that are built atop unsafe. It seems to kind of totally ruin the intended purpose of Rust as a language (to me, who is uninvolved).
- kibwen 5y ago
  That's perfectly valid, and you would likely benefit from the cargo-geiger tool mentioned above (or just plain-old grep for "unsafe").
- bsder 5y ago
  "unsafe" doesn't always mean unsafe. For example, you wish to implement a Vector in Rust. You generally don't want to allocate that Vector over and over, so you request more memory than you need. That "extra" memory is uninitialized which is a big no-no in Rust. You might be able to initialize that memory, but that will have performance implications that C/C++ programmers would just laugh at. However, your "invariant" is that you never access that memory until you have a real element that you put there. That's perfectly fine. Nevertheless, accessing that uninitialized area will always be "unsafe" from the Rust compiler point of view.
- iudqnolq 5y ago
  There has to be some unsafe, or else you can't have the parts of the standard library that interact with the OS. I'd at a minimum also include projects with experienced authors and similar needs such as tokio.