How to make C safe: by putting it back in the box and putting the box back on the shelf and then closing the door to the garage. Then using a safe-by-design language.
C and C++ simply weren't designed with safety in mind. Even with a good compiler and static analysis, security-critical bugs will slip through the net that simply wouldn't happen in other languages. It's not so much a question of whether it's possible to write safe C, but whether it's natural or easy. C is unsafe by default.
C has a number of safety-compromising properties that require positive human effort to counteract.
You can go a long way to counteracting some of these with automated toolchains.
You can probably go further by using languages which simply eliminate certain classes of error and then having the same level of toolchain elaboration.
That's not to say that C code can't be safe. It can absolutely be made safe. It just costs more, and any system that requires positive human effort is more likely to fail than one that doesn't.
I don't believe that it is possible to write safe C (or C++), even if you are both very careful and also among the most skilled C developers out there. Every sizable project in C has had critical vulnerabilities. It is not possible to train engineers on a team of any meaningful size to consistently write bug free code and catch bugs in code review. Sanitizers, fuzzing, and static analysis all help but are insufficient in the face of the utterly impossible task of writing safe C programs, let alone evolving safe C programs.
Look at all the very smart people that tried and completely failed to write libraries that do such basic things as copying strings.
You don't write those parts in C alone. You use something that shows the C is safe automatically, use tool that generates secure C from specs (eg Nail), and/ use safe language that compiles to C. This way, you get benefits of C ecosystem without risks of totally using C.
C lets you deliberately do unsafe memory programming, which is maybe OK if you actually know what you're doing. But C also lets you think that you're doing safe memory programming, when that is not the case.
C is not just unsafe in the sense that it supports unsafe behavior.
It's unsafe in the sense that it's nearly impossible for even clever, experienced programmers to write nontrivial amounts of code in it that don't have foot-shooting behavior in some form.
C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.
The problem is C shouldn't be as safe as your design as skills, modern languages provide assurances that prevent programmers from shooting themselves in the foot and as we know, all programmers do that sometimes.
The people who rant most (to zealot levels) about “unsafe C” are the most likely to write horribly insecure code in whatever their “safe” language of choice is.
It reminds me of early aviation tech like computers, autopilot, fly-by-wire, etc. In many cases accident rates went up initially because pilots (very wrongly) assumed all of these magical newfangled technologies could just fix and handle everything.
I’m not saying C isn’t fundamentally unsafe but your favorite memory safe language isn’t a cure-all and I can’t remotely understand how you could think it is.
A lot of the safety issues in C have been decently solved, though. You just have to use a larger tool chain than just the compiler. (Valgrind, coverity, etc.)
The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot of code (which can at times hard to read, especially if you have not completely linear control flow). Looking at just the declaration is a small part of the issue.
reply