> This is a very talented team on a very small and well scoped project. It can be written properly.

Talent does not preclude you from making mistakes

Most projects start out small and well scoped. That doesn’t mean it’s going to last.

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.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.

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.

> 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...

> 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

Your point stands though: well written modern C++ should be much less prone to memory-safety issues than well written modern C.

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.

[0]: https://curl.se/docs/CVE-2019-5482.html

[1]: https://curl.se/docs/CVE-2019-3823.html

(among numerous others)

[2]: https://www.darkreading.com/attacks-breaches/researchers-sho...

[3]: 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/

[5]: https://www.cvedetails.com/cve/CVE-2018-15471/

And yet NASA uses C, not Rust.

I don't think you want to develop your software project like the NASA develops its critical software projects.

Indeed. Pretending it isn’t is equally silly.

External static analyzers also improved a lot.

You can ensure memory-safety in C by enforcing strict rules since the first commit.

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?