3 ms·

> For the folks who really can write UB-free C, how many years did it take you to get to that point? There is an easier path: you can test your C or C++ stuff

> For the folks who really can write UB-free C, how many years did it take you to get to that point? There is an easier path: you can test your C or C++ stuff with valgrind and get reasonable certainty that it work. However nowadays we are putting our trust in the borrow checker, and quietly ignore the fact that half of the rust stuff needs to use the 'unsafe' keyword.

flohofwoe 4y ago
For 'actual undefined behaviour' Clang's UBSAN is the better choice though (and for completeness: -Wall, -Wextra, --analyze or better clang-tidy and finally ASAN and TSAN).
thesuperbigfrog 4y ago
>> half of the rust stuff needs to use the 'unsafe' keyword. If this is true for the Rust code you are writing, either you are doing it wrong or perhaps you are writing lots of low-level embedded / drivers code? Having written C and C++ for years and now learning Rust, I much prefer the safety and nice features of Rust. Coding in C and C++ now feels like driving in a car without a seatbelt: you can do it if you don't have other options, but if you do have the choice, why wouldn't you?
- steveklabnik 4y ago
  Even for low/level embedded drivers code, you don't use 50% unsafe.
  - thesuperbigfrog 4y ago
    In that case, it is being done wrong. I haven't had to use unsafe Rust yet, but have had to do some squirrely C tricks in the past for really low-level stuff.
oconnor663 4y ago
Both Rust and C/C++ have some important limitations when it comes to being categorically UB-free. Rust's limitations first: - If there's `unsafe` code in your dependencies, that's potentially just as bad as `unsafe` code in your own project. So you do have to be careful with what you pull in. - There are known "soundness holes" in the compiler, i.e. compiler bugs that let you corrupt memory without writing `unsafe`. However, the ones that remain are pretty obscure and very hard to hit accidentally. Now C and C++'s limitations: - Valgrind and all the sanitizers depend on test coverage. So 100% line coverage is table stakes for getting certainty out of these. And you probably also need to think about coverage of your dependencies. - None of these tools catch the UB that results from violating the "strict aliasing" rules. I believe there's something called "TypeSan" that promises to improve this situation, but it's experimental?

flohofwoe 4y ago

For 'actual undefined behaviour' Clang's UBSAN is the better choice though (and for completeness: -Wall, -Wextra, --analyze or better clang-tidy and finally ASAN and TSAN).

thesuperbigfrog 4y ago

>> half of the rust stuff needs to use the 'unsafe' keyword. If this is true for the Rust code you are writing, either you are doing it wrong or perhaps you are writing lots of low-level embedded / drivers code? Having written C and C++ for years and now learning Rust, I much prefer the safety and nice features of Rust. Coding in C and C++ now feels like driving in a car without a seatbelt: you can do it if you don't have other options, but if you do have the choice, why wouldn't you?

steveklabnik 4y ago
Even for low/level embedded drivers code, you don't use 50% unsafe.
- thesuperbigfrog 4y ago
  In that case, it is being done wrong. I haven't had to use unsafe Rust yet, but have had to do some squirrely C tricks in the past for really low-level stuff.

oconnor663 4y ago

Both Rust and C/C++ have some important limitations when it comes to being categorically UB-free. Rust's limitations first: - If there's `unsafe` code in your dependencies, that's potentially just as bad as `unsafe` code in your own project. So you do have to be careful with what you pull in. - There are known "soundness holes" in the compiler, i.e. compiler bugs that let you corrupt memory without writing `unsafe`. However, the ones that remain are pretty obscure and very hard to hit accidentally. Now C and C++'s limitations: - Valgrind and all the sanitizers depend on test coverage. So 100% line coverage is table stakes for getting certainty out of these. And you probably also need to think about coverage of your dependencies. - None of these tools catch the UB that results from violating the "strict aliasing" rules. I believe there's something called "TypeSan" that promises to improve this situation, but it's experimental?