4 ms·

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-fr

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory safety bugs (extreme pro level, super hard to exploit, only worth it in massively adopted evil outer world facing software) can be fixed by using C++26 with array bounds checking and forced initialisation. These last two things that Rust forces catch 70-80% of the memory problems the borrow checker only 20-30% only use-after-free. Most problems by far for normal developers are supply chain attacks, exposing api keys, remote code execution, wrong input validation, wrong auth-flow. You're reading the CVEs of sudo and ssh and think your code will be hacked like that. PHP is memory safe and still many people hack wordpress plugins.

slopinthebag 4mo ago
Any sources for these numbers?
- lawn 4mo ago
  90℅ of all statistics is made up.
- Sohcahtoa82 4mo ago
  https://www.youtube.com/watch?v=r7l0Rq9E8MY&t=2s https://www.youtube.com/watch?v=r7l0Rq9E8MY&t=2s
- jurschreuder 4mo ago
  Yes all of them have sources. Look for example top 500 CVEs of this year (after many fixes in C++, not right when the 70% memory issues in Chrome came out). Look at top 10 CVE github 2025 (zero memory related does not make it). Look at that sudo-rs was not allowed in Ubuntu because it's not as safe (way worst track record) than the C version, almost all is input sanitation. Look at wordpress plugins hacks, all PHP all memory safe language. Compare that to HAProxy and Nginx (C). Etc.
khuey 4mo ago
> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed] Google says memory safety issues are 75% of exploited zero days. (https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html https://security.googleblog.com/2024/10/safer-with-google-ad...)
- kalaksi 4mo ago
  And at least in Chromium project, half of those memory safety issues are use-after-free: https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
  - jurschreuder 4mo ago
    Then you're looking at very old data, recent top 500 CVE's 100% of the use-after-free exploits where escalation to Admin on Windows.
- bbippin 4mo ago
  The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.
  - khuey 4mo ago
    > The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.
    - 4mo ago
chilljinx 4mo ago
I do not believe that I agree, and I am not sure about all of your numbers. The borrow checker does add something, but it definitely costs something as well in multiple ways, also in terms of how it is done in Rust and at a programming language design perspective. It would be very funny if you were batting for Rust, and just having a laugh at others here.
jeffbee 4mo ago
Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid stored reference even if you have cranked up the hardening mode to DEBUG. Rust, on the other hand, affirmatively prevents that.
- nulltrace 4mo ago
  [dead]
- jurschreuder 4mo ago
  You can also write inline assembly in C++ and then it's not safe. But no developers working on projects that have been so ultimately battle tested that only memory safety issues remain do that. Professional C++ developers use RAII and containers. If you use raw pointers or raw arrays in C++ you will get 200 code reviewers lecturing you. You will never be able to for long.
pengaru 4mo ago
"extreme pro level" how old are you?

slopinthebag 4mo ago

Any sources for these numbers?

lawn 4mo ago
90℅ of all statistics is made up.
Sohcahtoa82 4mo ago
https://www.youtube.com/watch?v=r7l0Rq9E8MY&t=2s https://www.youtube.com/watch?v=r7l0Rq9E8MY&t=2s
jurschreuder 4mo ago
Yes all of them have sources. Look for example top 500 CVEs of this year (after many fixes in C++, not right when the 70% memory issues in Chrome came out). Look at top 10 CVE github 2025 (zero memory related does not make it). Look at that sudo-rs was not allowed in Ubuntu because it's not as safe (way worst track record) than the C version, almost all is input sanitation. Look at wordpress plugins hacks, all PHP all memory safe language. Compare that to HAProxy and Nginx (C). Etc.

khuey 4mo ago

> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed] Google says memory safety issues are 75% of exploited zero days. (https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html https://security.googleblog.com/2024/10/safer-with-google-ad...)

kalaksi 4mo ago
And at least in Chromium project, half of those memory safety issues are use-after-free: https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- jurschreuder 4mo ago
  Then you're looking at very old data, recent top 500 CVE's 100% of the use-after-free exploits where escalation to Admin on Windows.
bbippin 4mo ago
The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.
- khuey 4mo ago
  > The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.
  - 4mo ago

chilljinx 4mo ago

I do not believe that I agree, and I am not sure about all of your numbers. The borrow checker does add something, but it definitely costs something as well in multiple ways, also in terms of how it is done in Rust and at a programming language design perspective. It would be very funny if you were batting for Rust, and just having a laugh at others here.

jeffbee 4mo ago

Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid stored reference even if you have cranked up the hardening mode to DEBUG. Rust, on the other hand, affirmatively prevents that.

nulltrace 4mo ago
[dead]
jurschreuder 4mo ago
You can also write inline assembly in C++ and then it's not safe. But no developers working on projects that have been so ultimately battle tested that only memory safety issues remain do that. Professional C++ developers use RAII and containers. If you use raw pointers or raw arrays in C++ you will get 200 code reviewers lecturing you. You will never be able to for long.

pengaru 4mo ago

"extreme pro level" how old are you?