5 ms·

There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and

by dannersy 10mo ago

There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward? The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.

yourdetect 10mo ago
> Should we remove C or Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities. The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language. What Linus wrote in the past: https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust. That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
- dannersy 10mo ago
  But this sounds like hubris and user error, then, and not a language discussion at all?
uecker 10mo ago
I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
- aw1621107 10mo ago
  > Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic. > So the fact that there are also such bugs in Rust Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
  - uecker 10mo ago
    I agree with you that this is more nuanced and that I oversimplified this a bit in my comment.
- bitwize 10mo ago
  Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
  - noosphr 10mo ago
    The safest computer is a rock. The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.

yourdetect 10mo ago

> Should we remove C or Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities. The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language. What Linus wrote in the past: https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust. That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.

dannersy 10mo ago
But this sounds like hubris and user error, then, and not a language discussion at all?

uecker 10mo ago

I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.

aw1621107 10mo ago
> Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic. > So the fact that there are also such bugs in Rust Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
- uecker 10mo ago
  I agree with you that this is more nuanced and that I oversimplified this a bit in my comment.
bitwize 10mo ago
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
- noosphr 10mo ago
  The safest computer is a rock. The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.