6 ms·

What are you talking about, the language gets better with each release. Using C++ today is a hell of a lot better than even 10 years ago. It seems like people h

by mempko 2y ago

What are you talking about, the language gets better with each release. Using C++ today is a hell of a lot better than even 10 years ago. It seems like people hold "memory safety" as the most important thing a language can have. I completely disagree. It turns out you can build awesome and useful software without memory safety. And it's not clear if memory safety is the largest source of problems building software today. In my opinion, having good design and architecture are much higher on my list than memory safety. Being able to express my mental model as directly as possible is more important to me.

nindalf 2y ago
> And it's not clear if memory safety is the largest source of problems building software today. The Chromium team found that > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Chromium Security: Memory Safety (https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...) Microsoft found that > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues A proactive approach to more secure code (https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...) It’s possible you hadn’t come across these studies before. But if you have, and you didn’t find them convincing, what did they lack? - Were the codebases not old enough? They’re anywhere between 15 and 30 years old, so probably not. - Did the codebases not have enough users? I think both have billions of active users, so I don’t think so. - Was it a “skill issue”? Are the developers at Google and Microsoft just not that good? Maybe they didn’t consider good design and architecture at any point while writing software over the last couple of decades. Possible! There’s just one problem with the “skill issue” theory though. Android, presumably staffed with the same calibre of engineers as Chrome, also written in C++ also found that 76% of vulnerabilities were related to memory safety. We’ve got consistency, if nothing else. And then, in recent years, something remarkable happened. > the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages. Eliminating Memory Safety Vulnerabilities at the Source (https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1 https://security.googleblog.com/2024/09/eliminating-memory-s...) They stopped writing new C++ code and the memory safety vulnerabilities dropped dramatically. Billions of Android users are already benefiting from much more secure devices, today! You originally said > And it's not clear if memory safety is the largest source of problems building software today. It is possible to defend this by saying “what matters in software is product market fit” or something similar. That would be technically correct, while side stepping the issue. Instead I’ll ask you, do you still think it is possible to write secure software in C++, but just trying a little harder. Through “good design and architecture”, as your previous comment implied.
- otabdeveloper4 2y ago
  I million times more systems were infiltrated due to PHP SQL injection bugs than were infiltrated via Chromium use-after-free bugs. Let's keep some sanity and perspective here, please. C++ has many long-standing problems, but banging on the "security" drum will only drive people away from alternative languages. (Everyone knows that "security" is just a fig leaf they use to strong-arm you into doing stuff you hate.)
- jpc0 2y ago
  > Around 70% of our high severity security bugs are memory unsafety problems > ~70% of the vulnerabilities Microsoft assigns a CVE > 76% of vulnerabilities What is the difference between the first two (emphasis added) and what you said? Just as a thought experiment... If I measure a single factor in exclusion to all others I can also find whatever I want in any set of data. Now your point may be valid but it is not what they published and without the full dataset we cannot validate your claim however I can validate that what you claim is no what they claim. To answer your question in the final paragraph. Yes it is, but it requires the same cultural shift as what it would take to write the same code in rust or swift of golang or whatever other memory safe language you want to pick. If rust was in fact viable for such a large project, how's the servo project going? That still the resounding success it was expected to be? Rust in the kernel? That going well? The jury is still out on whether rust will be mass adopted and is able to usurp C/C++ in the domains where C/C++ dominate. It may get there, but I would much much rather start a new project using C++20 than in rust and I would still be able to make it memory safe and yes it is a "skill issue", but purely because of legacy C++ being taught and accepted in new code in a codebase. Rules for writing memory safe C++ has not just been around for decades but has be statically checkable for over a decade but for a large project there are too many errors to universally apply them to existing code without years of work. However if you submit new code using old practices you should be held financially and legally responsible just like an actual engineer in another field would be. It's because we are lax about standards that it's even an issue. As a note, if you see an Arc<Mutex<>> in rust outside of some very specific Library code whoever wrote that code probably wouldn't be able to write the same code in a memory and thread safe manner, also that is an architectural issue. Arc and Mutex are synchronisation primatives that are meant to be used to build datastructures and not in "userspace" code. It's a strong code smell that is generally accepted in Rust. Arc probably shouldn't even need to exist at all because that is a clear indication nobody thought about the ownership semantics of the data in question, maybe for some datastructures it is required but you should very likely not be typing it into general code. If Arc<Mutex<>> is littered throughout your rust codebase you probably should have written that code in C#/Java/Go/pick your poison...
WalterBright 2y ago
The top memory safety bugs in shipped code for C and C++ are out of bounds array indexing.
- saagarjha 2y ago
  Are you sure? I generally see more use-after-free and other lifetime issues.
  - WalterBright 2y ago
    Every survey I've seen corroborated it.
tobias12345 2y ago
Does it matter whether it is a common class of bugs or a not so common one? The point is, this is a class of bugs you do not have when picking a different language. C++ claimed for decades to be about eliminating a class of resource management bugs you can have in C code, that was its biggest selling point. So why is eliminating another class of bugs a nice to have now? C++ is loosing projects to memory safe languages for decades now, just think of all the business software in Java, scientific SW in python, ... . The industry is moving towards memory safe software for decades now. Rust is just the newest option -- and a very compelling one as it has no runtime environment or garbage collector, just like C++.

by mempko 2y ago

nindalf 2y ago

> And it's not clear if memory safety is the largest source of problems building software today. The Chromium team found that > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Chromium Security: Memory Safety (https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...) Microsoft found that > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues A proactive approach to more secure code (https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...) It’s possible you hadn’t come across these studies before. But if you have, and you didn’t find them convincing, what did they lack? - Were the codebases not old enough? They’re anywhere between 15 and 30 years old, so probably not. - Did the codebases not have enough users? I think both have billions of active users, so I don’t think so. - Was it a “skill issue”? Are the developers at Google and Microsoft just not that good? Maybe they didn’t consider good design and architecture at any point while writing software over the last couple of decades. Possible! There’s just one problem with the “skill issue” theory though. Android, presumably staffed with the same calibre of engineers as Chrome, also written in C++ also found that 76% of vulnerabilities were related to memory safety. We’ve got consistency, if nothing else. And then, in recent years, something remarkable happened. > the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages. Eliminating Memory Safety Vulnerabilities at the Source (https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1 https://security.googleblog.com/2024/09/eliminating-memory-s...) They stopped writing new C++ code and the memory safety vulnerabilities dropped dramatically. Billions of Android users are already benefiting from much more secure devices, today! You originally said > And it's not clear if memory safety is the largest source of problems building software today. It is possible to defend this by saying “what matters in software is product market fit” or something similar. That would be technically correct, while side stepping the issue. Instead I’ll ask you, do you still think it is possible to write secure software in C++, but just trying a little harder. Through “good design and architecture”, as your previous comment implied.

otabdeveloper4 2y ago
I million times more systems were infiltrated due to PHP SQL injection bugs than were infiltrated via Chromium use-after-free bugs. Let's keep some sanity and perspective here, please. C++ has many long-standing problems, but banging on the "security" drum will only drive people away from alternative languages. (Everyone knows that "security" is just a fig leaf they use to strong-arm you into doing stuff you hate.)
jpc0 2y ago
> Around 70% of our high severity security bugs are memory unsafety problems > ~70% of the vulnerabilities Microsoft assigns a CVE > 76% of vulnerabilities What is the difference between the first two (emphasis added) and what you said? Just as a thought experiment... If I measure a single factor in exclusion to all others I can also find whatever I want in any set of data. Now your point may be valid but it is not what they published and without the full dataset we cannot validate your claim however I can validate that what you claim is no what they claim. To answer your question in the final paragraph. Yes it is, but it requires the same cultural shift as what it would take to write the same code in rust or swift of golang or whatever other memory safe language you want to pick. If rust was in fact viable for such a large project, how's the servo project going? That still the resounding success it was expected to be? Rust in the kernel? That going well? The jury is still out on whether rust will be mass adopted and is able to usurp C/C++ in the domains where C/C++ dominate. It may get there, but I would much much rather start a new project using C++20 than in rust and I would still be able to make it memory safe and yes it is a "skill issue", but purely because of legacy C++ being taught and accepted in new code in a codebase. Rules for writing memory safe C++ has not just been around for decades but has be statically checkable for over a decade but for a large project there are too many errors to universally apply them to existing code without years of work. However if you submit new code using old practices you should be held financially and legally responsible just like an actual engineer in another field would be. It's because we are lax about standards that it's even an issue. As a note, if you see an Arc<Mutex<>> in rust outside of some very specific Library code whoever wrote that code probably wouldn't be able to write the same code in a memory and thread safe manner, also that is an architectural issue. Arc and Mutex are synchronisation primatives that are meant to be used to build datastructures and not in "userspace" code. It's a strong code smell that is generally accepted in Rust. Arc probably shouldn't even need to exist at all because that is a clear indication nobody thought about the ownership semantics of the data in question, maybe for some datastructures it is required but you should very likely not be typing it into general code. If Arc<Mutex<>> is littered throughout your rust codebase you probably should have written that code in C#/Java/Go/pick your poison...

WalterBright 2y ago

The top memory safety bugs in shipped code for C and C++ are out of bounds array indexing.

saagarjha 2y ago
Are you sure? I generally see more use-after-free and other lifetime issues.
- WalterBright 2y ago
  Every survey I've seen corroborated it.

tobias12345 2y ago

Does it matter whether it is a common class of bugs or a not so common one? The point is, this is a class of bugs you do not have when picking a different language. C++ claimed for decades to be about eliminating a class of resource management bugs you can have in C code, that was its biggest selling point. So why is eliminating another class of bugs a nice to have now? C++ is loosing projects to memory safe languages for decades now, just think of all the business software in Java, scientific SW in python, ... . The industry is moving towards memory safe software for decades now. Rust is just the newest option -- and a very compelling one as it has no runtime environment or garbage collector, just like C++.