4 ms·

Unsafe is not as big of a deal as people make it seem.

by adamnemecek 6y ago

pjmlp 6y ago
Using C alongside static analysis like Frama-C is also quite safe, one could say.
- adamnemecek 6y ago
  It's not just safety though. It's just...all of it. I legit don't enjoy writing C. Rust is fun to write 90% of the time.
  - keldaris 6y ago
    That's a completely fair point, but very subjective. There are lots of people (myself included) who feel exactly the opposite way.
- Jweb_Guru 6y ago
  Frama-C's analysis is neither sound nor complete and it's way way harder to set up and use than Rust.
  - pjmlp 6y ago
    As someone that has enough C and C++ experience going back to 1992, worked at CERN and Nokia in very complicated C++ codebases and still has issues with the borrow checker and when to annotate what, I beg to differ how easy it is to use Rust, although I do conceed it has gotten much better.
    - Jweb_Guru 6y ago
      I am well aware of your opinions on this matter. None of what you just said has anything to do with Frama-C. You can't throw that out there as a Rust alternative (which, as I noted, it is not, or at least not a complete one) and then compare how easy "vanilla C++" is compared to Rust (like I said, I disagree with you on that, but it's not even relevant here). The truth is that for people who care about safety (as I know you and I do), want to use an unmanaged language (for whatever reason), and don't want to use Ada (no accounting for taste, I guess), the "correct" comparison is C and C++ with a load of static analysis tools that don't quite work, miss plenty of bugs, enable dynamic protection that slows down your program, are not easy to install, and can be terribly noisy when not configured extensively for your project... vs. Rust which works out of the box, has the analysis integrated into the typechecker, has a simple installation and upgrade process, and catches everything. In that competition, Rust wins every time.
      - pjmlp 6y ago
        Almost fully agree, just the ergonomics are fully there and while static analysis tools aren't fully there, nor ever will, as you well point out, the likes of Google and Microsoft seem quite minded to bring Rust into C++, despite their ongoing adoption of Rust. As the latest posts from Visual C++ seem to imply, https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... https://cppcon2020.sched.com/event/e7C0/introducing-microsofts-new-open-source-fuzzing-platform https://cppcon2020.sched.com/event/e7C0/introducing-microsof... Because the language alone isn't enough, the existing eco-system and tooling also plays a big role. Since we are speaking about games here, C++ just hit the jackpot with GPGPU programming, even though other languages are also supported in PTX and SPIR-V. So I am actually curious how far the companies with seat at ISO C++ are actually going to adopt Rust on their platforms, versus briging Rust learnings into C++.
        Jweb_Guru 6y ago
        Microsoft, sure--nobody has worked harder than they have to try to make C++ safer. And there are other big companies seriously investing in making C++ safer (e.g. Facebook, bad as they are otherwise). But I've also talked to many of the researchers actually working on these projects--they'll freely tell you how hard the task is and how impossible it is to really apply Rust's straightforward solutions to the massive existing legacy of C++ code. And let's be honest--if your tool requires people to rewrite everything anyway, they might as well choose Rust, so it's not acceptable for your tool to only work on modern stuff, or require annotations everywhere you use std::string_view, etc. And I should be very clear that this is quite specific to C and C++. Ada, for example, has been able to adopt solutions from Rust with ease, and even add some interesting improvements, because the safe subset of their language was conservative and the borrow checker allows them to extend it. So I'm not saying other languages cannot copy Rust, it's very much specific to unsafe by design languages like C++. They're trying to make their existing codebases safer, and I think that's great, but unless there's a massive breakthrough in the next few years these aren't going to be general purpose solutions and they are definitely not going to be close to sound. For example, pretty much everything I'm aware of for C++ that tries to do memory safety, punts on thread safety, because it's just virtually impossible with all the other stuff going on; many of them punt on recursive function calls, and a bunch don't even do anything but very basic interprocedural analysis, focusing all their energy on "local" intraprocedural bugs that are much easier to catch. The tools would just be too noisy to be useful otherwise. As for Google... they resisted investing in static analysis tools for years and I don't take them seriously at all when they talk about this sort of thing.
- atoav 6y ago
  If this is safe, why do we still have all these bugs? Because people don't use it? Because people who use it ignore it? Because it doesn't manage to catch all things the Rust compiler would? I am all for making C safer, but clearly it doesn't seem to work, with all these use after free bugs you can still find in 2020 C code.
  - pjmlp 6y ago
    Another one that hasn't got the irony of my comment. But yes most devs don't use static analysis tools nor unit tests, unless required by law, as proven by multiple surveys.
    - atoav 6y ago
      Whether your post was ironic or not was not really decideable based on the words you wrote (and I am usually not bad at spotting irony). Maybe you'll strike a better balance next time.
estebank 6y ago
It's also not nearly as prevalent as people from outside the ecosystem seem to think it is. I read a lot of "any non-trivial Rust code will have to use unsafe" and I guess that means that all of the code I've worked on is trivial.
- ordu 6y ago
  I believe if we dug into things deeper, we would find that "non-trivial code" here means "code that doesn't need unsafe". Developers of rust and std do a great job to cover all the "non-trivial" cases by the std types. Everything covered by them doesn't seem non-trivial anymore. So... here we are.
- pjmlp 6y ago
  The work being continuously done to improve the state of unsafe on crates.io proves otherwise. That is my point, people continue to use "C with Classes" because they don't know better or were poorly taught, likewise many reach out to unsafe as they cannot make it work otherwise and leave the code like that. In a world with a very thin standard library and an npm like dependency tree, every crate might be full of unsafe surprises that one is only aware if going through all of them. And this in a scenario where cargo doesn't do binary dependencies.
  - Jweb_Guru 6y ago
    Only about 1% of Rust code is unsafe. We can still expect that 1% to be just as full of memory safety bugs as C++, so it's obviously important to clean those crates up, but that's a pretty huge improvement. It's also much easier (actually tractable, in many cases) to completely review a dependency's uses of unsafe, compared to doing a thorough code review of an entire dependency as you would have to do in C or C++ to get the same guarantees.

Unsafe is not as big of a deal as people make it seem.

pjmlp 6y ago

Using C alongside static analysis like Frama-C is also quite safe, one could say.

adamnemecek 6y ago
It's not just safety though. It's just...all of it. I legit don't enjoy writing C. Rust is fun to write 90% of the time.
- keldaris 6y ago
  That's a completely fair point, but very subjective. There are lots of people (myself included) who feel exactly the opposite way.
Jweb_Guru 6y ago
Frama-C's analysis is neither sound nor complete and it's way way harder to set up and use than Rust.
- pjmlp 6y ago
  As someone that has enough C and C++ experience going back to 1992, worked at CERN and Nokia in very complicated C++ codebases and still has issues with the borrow checker and when to annotate what, I beg to differ how easy it is to use Rust, although I do conceed it has gotten much better.
  - Jweb_Guru 6y ago
    I am well aware of your opinions on this matter. None of what you just said has anything to do with Frama-C. You can't throw that out there as a Rust alternative (which, as I noted, it is not, or at least not a complete one) and then compare how easy "vanilla C++" is compared to Rust (like I said, I disagree with you on that, but it's not even relevant here). The truth is that for people who care about safety (as I know you and I do), want to use an unmanaged language (for whatever reason), and don't want to use Ada (no accounting for taste, I guess), the "correct" comparison is C and C++ with a load of static analysis tools that don't quite work, miss plenty of bugs, enable dynamic protection that slows down your program, are not easy to install, and can be terribly noisy when not configured extensively for your project... vs. Rust which works out of the box, has the analysis integrated into the typechecker, has a simple installation and upgrade process, and catches everything. In that competition, Rust wins every time.
    - pjmlp 6y ago
      Almost fully agree, just the ergonomics are fully there and while static analysis tools aren't fully there, nor ever will, as you well point out, the likes of Google and Microsoft seem quite minded to bring Rust into C++, despite their ongoing adoption of Rust. As the latest posts from Visual C++ seem to imply, https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... https://cppcon2020.sched.com/event/e7C0/introducing-microsofts-new-open-source-fuzzing-platform https://cppcon2020.sched.com/event/e7C0/introducing-microsof... Because the language alone isn't enough, the existing eco-system and tooling also plays a big role. Since we are speaking about games here, C++ just hit the jackpot with GPGPU programming, even though other languages are also supported in PTX and SPIR-V. So I am actually curious how far the companies with seat at ISO C++ are actually going to adopt Rust on their platforms, versus briging Rust learnings into C++.
      - Jweb_Guru 6y ago
        Microsoft, sure--nobody has worked harder than they have to try to make C++ safer. And there are other big companies seriously investing in making C++ safer (e.g. Facebook, bad as they are otherwise). But I've also talked to many of the researchers actually working on these projects--they'll freely tell you how hard the task is and how impossible it is to really apply Rust's straightforward solutions to the massive existing legacy of C++ code. And let's be honest--if your tool requires people to rewrite everything anyway, they might as well choose Rust, so it's not acceptable for your tool to only work on modern stuff, or require annotations everywhere you use std::string_view, etc. And I should be very clear that this is quite specific to C and C++. Ada, for example, has been able to adopt solutions from Rust with ease, and even add some interesting improvements, because the safe subset of their language was conservative and the borrow checker allows them to extend it. So I'm not saying other languages cannot copy Rust, it's very much specific to unsafe by design languages like C++. They're trying to make their existing codebases safer, and I think that's great, but unless there's a massive breakthrough in the next few years these aren't going to be general purpose solutions and they are definitely not going to be close to sound. For example, pretty much everything I'm aware of for C++ that tries to do memory safety, punts on thread safety, because it's just virtually impossible with all the other stuff going on; many of them punt on recursive function calls, and a bunch don't even do anything but very basic interprocedural analysis, focusing all their energy on "local" intraprocedural bugs that are much easier to catch. The tools would just be too noisy to be useful otherwise. As for Google... they resisted investing in static analysis tools for years and I don't take them seriously at all when they talk about this sort of thing.
atoav 6y ago
If this is safe, why do we still have all these bugs? Because people don't use it? Because people who use it ignore it? Because it doesn't manage to catch all things the Rust compiler would? I am all for making C safer, but clearly it doesn't seem to work, with all these use after free bugs you can still find in 2020 C code.
- pjmlp 6y ago
  Another one that hasn't got the irony of my comment. But yes most devs don't use static analysis tools nor unit tests, unless required by law, as proven by multiple surveys.
  - atoav 6y ago
    Whether your post was ironic or not was not really decideable based on the words you wrote (and I am usually not bad at spotting irony). Maybe you'll strike a better balance next time.

estebank 6y ago

It's also not nearly as prevalent as people from outside the ecosystem seem to think it is. I read a lot of "any non-trivial Rust code will have to use unsafe" and I guess that means that all of the code I've worked on is trivial.

ordu 6y ago
I believe if we dug into things deeper, we would find that "non-trivial code" here means "code that doesn't need unsafe". Developers of rust and std do a great job to cover all the "non-trivial" cases by the std types. Everything covered by them doesn't seem non-trivial anymore. So... here we are.
pjmlp 6y ago
The work being continuously done to improve the state of unsafe on crates.io proves otherwise. That is my point, people continue to use "C with Classes" because they don't know better or were poorly taught, likewise many reach out to unsafe as they cannot make it work otherwise and leave the code like that. In a world with a very thin standard library and an npm like dependency tree, every crate might be full of unsafe surprises that one is only aware if going through all of them. And this in a scenario where cargo doesn't do binary dependencies.
- Jweb_Guru 6y ago
  Only about 1% of Rust code is unsafe. We can still expect that 1% to be just as full of memory safety bugs as C++, so it's obviously important to clean those crates up, but that's a pretty huge improvement. It's also much easier (actually tractable, in many cases) to completely review a dependency's uses of unsafe, compared to doing a thorough code review of an entire dependency as you would have to do in C or C++ to get the same guarantees.