3 ms·

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

by SEJeff 6y ago

MaxBarraclough 6y ago
The Linux kernel still has memory safety issues to this day. The C++ approach is to offer a feature-rich language so the programmer doesn't have to reinvent common abstractions. The C approach is to offer a minimal and stable language and let the programmer take it from there. It's not obvious a priori which approach should result in fewer memory safety issues. If I had to guess my money would be on C++ being the better choice, as it has smart pointers.
coder543 6y ago
Saying C is easier to secure than Modern C++ is just confusing. The point of a lot of recent C++ features is to make memory safety easier to achieve. I personally don't think it gets anywhere close to safe enough for me to recommend, when Rust is such a competent option that people can choose instead. I would still rather people have the tools of C++ at their disposal instead of having to do everything themselves in C. Please find me a well-known C code base that doesn't suffer from memory safety CVEs. You're the one making the claim that they exist... I can't prove that such a thing doesn't exist, but I can point to how curl[0][1], sqlite[2][3], the linux kernel[4][5], and any other popular, respected C code base that I can think of suffers from numerous memory safety issues that memory safe languages are built to prevent. Writing secure software is hard enough without picking a memory unsafe language as the foundation of that software. "Just find/be a better programmer" isn't the solution. We've tried that for decades with little success. The continued prevalence of memory safety vulnerability in these C code bases shows that existing static analysis tools are insufficient for handling the many ways that things can go wrong in C. I think you mentioned railcar elsewhere in this thread, and I would find it easier to be interested in a runc alternative that is written in a memory safe language... which railcar is. [0]: https://curl.se/docs/CVE-2019-5482.html https://curl.se/docs/CVE-2019-5482.html [1]: https://curl.se/docs/CVE-2019-3823.html https://curl.se/docs/CVE-2019-3823.html (among numerous others) [2]: https://www.darkreading.com/attacks-breaches/researchers-show-how-sqlite-can-be-modified-to-attack-apps/d/d-id/1335500 https://www.darkreading.com/attacks-breaches/researchers-sho... [3]: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SQLite http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SQLite (the second link has quite a few memory safety issues that are readily apparent, including several from SQLite that affected Chrome) [4]: https://www.cvedetails.com/cve/CVE-2019-11599/ https://www.cvedetails.com/cve/CVE-2019-11599/ [5]: https://www.cvedetails.com/cve/CVE-2018-15471/ https://www.cvedetails.com/cve/CVE-2018-15471/
adev_ 6y ago
> Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant. Yeah and C++ would be a way better language to write critical system daemon in 2020 than C. Both safer and more productive while keeping the exact same portability and performance as C when necessary. Most safety issues of C (buffer overflows, use-after-free, stack smash) are not a problem anymore in modern C++. Yes, writing new userland software in C in 2020(1) is non-sense. - Use at least C++ if you are conservative. - Use Rust if you aim for absolute safety. - Use Go if you accept the performance hit and do not need libraries. There is zero excuses to C in userland in 2020. The only excuse is some Red Hat folks seems to practice C++ hating as some kind of religion. That exactly what give us "beautiful" monstrosities like systemd or pulseaudio with their associated shopping list of CVEs [^1] Even GCC maintainers switched to C++, by the sake of god, do the same. ---- [^1]: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd...
- MaxBarraclough 6y ago
  > There is zero excuses to C in userland in 2020. I wouldn't go quite that far. I'm generally in the C++ camp (rather than C, that is) but there are significant advantages to a compact and stable language, and real disadvantages to a sprawling disaster like C++ that grows still more monstrously complex every few years. This topic turned up a year ago: https://news.ycombinator.com/item?id=21946060 https://news.ycombinator.com/item?id=21946060 Your point stands though: well written modern C++ should be much less prone to memory-safety issues than well written modern C.
- damudel 6y ago
  It's not feasible nor desireable to abandon C. Rather it is better to incrementally move to things like checked C, apply static analysis and perform formal proofs of correctness through Frama C and other tools. Do not use C++. Use Ada or Rust. GCC did not move to C++ for safety, but for the convenience C++ can provide. C++ is a very problematic language. It does not replace C due to its complexity.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

by SEJeff 6y ago

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

MaxBarraclough 6y ago

The Linux kernel still has memory safety issues to this day. The C++ approach is to offer a feature-rich language so the programmer doesn't have to reinvent common abstractions. The C approach is to offer a minimal and stable language and let the programmer take it from there. It's not obvious a priori which approach should result in fewer memory safety issues. If I had to guess my money would be on C++ being the better choice, as it has smart pointers.

coder543 6y ago

Saying C is easier to secure than Modern C++ is just confusing. The point of a lot of recent C++ features is to make memory safety easier to achieve. I personally don't think it gets anywhere close to safe enough for me to recommend, when Rust is such a competent option that people can choose instead. I would still rather people have the tools of C++ at their disposal instead of having to do everything themselves in C. Please find me a well-known C code base that doesn't suffer from memory safety CVEs. You're the one making the claim that they exist... I can't prove that such a thing doesn't exist, but I can point to how curl[0][1], sqlite[2][3], the linux kernel[4][5], and any other popular, respected C code base that I can think of suffers from numerous memory safety issues that memory safe languages are built to prevent. Writing secure software is hard enough without picking a memory unsafe language as the foundation of that software. "Just find/be a better programmer" isn't the solution. We've tried that for decades with little success. The continued prevalence of memory safety vulnerability in these C code bases shows that existing static analysis tools are insufficient for handling the many ways that things can go wrong in C. I think you mentioned railcar elsewhere in this thread, and I would find it easier to be interested in a runc alternative that is written in a memory safe language... which railcar is. [0]: https://curl.se/docs/CVE-2019-5482.html https://curl.se/docs/CVE-2019-5482.html [1]: https://curl.se/docs/CVE-2019-3823.html https://curl.se/docs/CVE-2019-3823.html (among numerous others) [2]: https://www.darkreading.com/attacks-breaches/researchers-show-how-sqlite-can-be-modified-to-attack-apps/d/d-id/1335500 https://www.darkreading.com/attacks-breaches/researchers-sho... [3]: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SQLite http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SQLite (the second link has quite a few memory safety issues that are readily apparent, including several from SQLite that affected Chrome) [4]: https://www.cvedetails.com/cve/CVE-2019-11599/ https://www.cvedetails.com/cve/CVE-2019-11599/ [5]: https://www.cvedetails.com/cve/CVE-2018-15471/ https://www.cvedetails.com/cve/CVE-2018-15471/

adev_ 6y ago

> Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant. Yeah and C++ would be a way better language to write critical system daemon in 2020 than C. Both safer and more productive while keeping the exact same portability and performance as C when necessary. Most safety issues of C (buffer overflows, use-after-free, stack smash) are not a problem anymore in modern C++. Yes, writing new userland software in C in 2020(1) is non-sense. - Use at least C++ if you are conservative. - Use Rust if you aim for absolute safety. - Use Go if you accept the performance hit and do not need libraries. There is zero excuses to C in userland in 2020. The only excuse is some Red Hat folks seems to practice C++ hating as some kind of religion. That exactly what give us "beautiful" monstrosities like systemd or pulseaudio with their associated shopping list of CVEs [^1] Even GCC maintainers switched to C++, by the sake of god, do the same. ---- [^1]: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd...

MaxBarraclough 6y ago
> There is zero excuses to C in userland in 2020. I wouldn't go quite that far. I'm generally in the C++ camp (rather than C, that is) but there are significant advantages to a compact and stable language, and real disadvantages to a sprawling disaster like C++ that grows still more monstrously complex every few years. This topic turned up a year ago: https://news.ycombinator.com/item?id=21946060 https://news.ycombinator.com/item?id=21946060 Your point stands though: well written modern C++ should be much less prone to memory-safety issues than well written modern C.
damudel 6y ago
It's not feasible nor desireable to abandon C. Rather it is better to incrementally move to things like checked C, apply static analysis and perform formal proofs of correctness through Frama C and other tools. Do not use C++. Use Ada or Rust. GCC did not move to C++ for safety, but for the convenience C++ can provide. C++ is a very problematic language. It does not replace C due to its complexity.