2 ms·

> Rust unsafe: the unsafe code is used in half of the libraries, first and third party, i.e. authored by very large group of people. There's no single binary, p

> Rust unsafe: the unsafe code is used in half of the libraries, first and third party, i.e. authored by very large group of people. There's no single binary, potential bugs are spread across entire ecosystem. Test coverage varies greatly, Vec from stdlib is used by everyone and very likely fine, but a long tail of unsafe code not used in practice much, or at all. Can't opt out this will disable Rust. I'm glad you agree that unsafe code in the standard Rust library is fine. Concern over unsafe code in dependencies is a legitimate concern, but it's one that we have tooling for, such as cargo-geiger. With that tooling, you can opt out of unsafe code in dependencies in Rust just as you can in Java. (Note that unsafe code isn't the biggest potential problem with dependencies, though. A malicious dependency is a serious issue, regardless of whether it does pointer arithmetic or not.) Besides, this is basically splitting hairs. Empirically, we know that memory safety problems are incredibly rare in Rust programs compared to those in C++ programs. Maybe Rust programs have slightly more memory safety problems than Java programs do, or vice versa. The difference isn't a meaningful one.

Const-me 7y ago
> I'm glad you agree that unsafe code in the standard Rust library is fine. I don't. I have no doubts in Vec class because it's used a lot, not because it's in the library. I'm pretty sure the standard library also has that long tail of barely tested unsafe code. I've recently looked at sources of stdsimd crate, it has hundreds of unsafe functions doing transmute. I code SIMD intrinsics a lot in C++ and I know they're probably OK. Apparently, wasn't even for pointer math, the only goal of unsafe was to workaround a language limitation (they're pure functions without side effects) > A malicious dependency is a serious issue I never found any, but I found bugs in my dependencies many times. Not fun either. > memory safety problems are incredibly rare in Rust programs compared to those in C++ programs I agree, quite expectable. BC works two ways, it checks ownership at compile time, also raises entry barrier. Both help with memory safety. The observations don't tell which effect contributes more.

Const-me 7y ago

> I'm glad you agree that unsafe code in the standard Rust library is fine. I don't. I have no doubts in Vec class because it's used a lot, not because it's in the library. I'm pretty sure the standard library also has that long tail of barely tested unsafe code. I've recently looked at sources of stdsimd crate, it has hundreds of unsafe functions doing transmute. I code SIMD intrinsics a lot in C++ and I know they're probably OK. Apparently, wasn't even for pointer math, the only goal of unsafe was to workaround a language limitation (they're pure functions without side effects) > A malicious dependency is a serious issue I never found any, but I found bugs in my dependencies many times. Not fun either. > memory safety problems are incredibly rare in Rust programs compared to those in C++ programs I agree, quite expectable. BC works two ways, it checks ownership at compile time, also raises entry barrier. Both help with memory safety. The observations don't tell which effect contributes more.