There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years 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.
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.
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.
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.
Can you share any good examples of C codebases that have enforced these rules and successfully avoided having memory safety problems?
Can you share any details on what rules a team could use to reliably avoid having memory safety problems when writing C?
