7 ms·

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 ju

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

dafelst 1y ago
In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program. Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.
- motorest 1y ago
  > In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages. Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
  - scott_w 1y ago
    > Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code. I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
    - motorest 1y ago
      > I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills? If that's the best argument, that's not an argument at all.
      - timeon 1y ago
        So why all the software is still so insecure?
        motorest 1y ago
        [flagged]
      - scott_w 1y ago
        > Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
  - 1y ago
michaelmrose 1y ago
Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.
- motorest 1y ago
  > Presumably because decades of experience has shown that it doesn't. What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code. https://nvd.nist.gov/vuln/detail/CVE-2025-48752 https://nvd.nist.gov/vuln/detail/CVE-2025-48752
  - anextio 1y ago
    This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly. https://github.com/Forestryks/process-sync-rs/issues/3 https://github.com/Forestryks/process-sync-rs/issues/3 One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust. In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
    - motorest 1y ago
      > This is not a very good example Feel free to pick an example that tickles your fancy. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
      - tialaramex 1y ago
        There are a few interesting trends in that list. One of them is that there's an increasing amount of Rust. People are going to write many of the high level bugs (e.g. logic mistakes) in any language, but if they're not using your language they won't write any in your language. Lots are written in Rust. But another is that the kind of things even reported is different. There's a case a while back where C++ and Rust have identical APIs which make an identical promise. The obvious way to implement that API on popular platforms introduces a TOCTOU race, and so that race was present in Rust's stdlib and in all three popular C++ standard library implementations. Rust reported the TOCTOU race and its fix, there's a CVE number. The three C++ libraries just decided it's a QOI issue and silently made equivalent changes over the next few months or years. In C++ the argument goes like this: C++ says that if any other programs are running on your computer, all filesystem access is Undefined Behaviour. Simply do not run more than one program per computer, then there's no TOCTOU race, no bug. Rust says duh, obviously multi-processing has been a thing since the 1960s so we have to assume other programs may be running, the TOCTOU race is a bug and must be fixed.

This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.

dafelst 1y ago

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program. Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.

motorest 1y ago
> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages. Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
- scott_w 1y ago
  > Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code. I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
  - motorest 1y ago
    > I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills? If that's the best argument, that's not an argument at all.
    - timeon 1y ago
      So why all the software is still so insecure?
      - motorest 1y ago
        [flagged]
    - scott_w 1y ago
      > Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
- 1y ago

michaelmrose 1y ago

Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.

motorest 1y ago
> Presumably because decades of experience has shown that it doesn't. What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code. https://nvd.nist.gov/vuln/detail/CVE-2025-48752 https://nvd.nist.gov/vuln/detail/CVE-2025-48752
- anextio 1y ago
  This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly. https://github.com/Forestryks/process-sync-rs/issues/3 https://github.com/Forestryks/process-sync-rs/issues/3 One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust. In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
  - motorest 1y ago
    > This is not a very good example Feel free to pick an example that tickles your fancy. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
    - tialaramex 1y ago
      There are a few interesting trends in that list. One of them is that there's an increasing amount of Rust. People are going to write many of the high level bugs (e.g. logic mistakes) in any language, but if they're not using your language they won't write any in your language. Lots are written in Rust. But another is that the kind of things even reported is different. There's a case a while back where C++ and Rust have identical APIs which make an identical promise. The obvious way to implement that API on popular platforms introduces a TOCTOU race, and so that race was present in Rust's stdlib and in all three popular C++ standard library implementations. Rust reported the TOCTOU race and its fix, there's a CVE number. The three C++ libraries just decided it's a QOI issue and silently made equivalent changes over the next few months or years. In C++ the argument goes like this: C++ says that if any other programs are running on your computer, all filesystem access is Undefined Behaviour. Simply do not run more than one program per computer, then there's no TOCTOU race, no bug. Rust says duh, obviously multi-processing has been a thing since the 1960s so we have to assume other programs may be running, the TOCTOU race is a bug and must be fixed.