We had sanitizers since C exists, 1979 to be more exact.
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. "
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.
The issue is that you’re trading a problem space that is very well understood for one that isn’t. Making a safe program in C is all about being explicit about resource allocation and controlling resources. So we tend to require that habit in development. It’s socialized. The only thing you’d be doing is using technology to replace the socialization. And you’d be adding new problems from Rust that don’t exist in the C world.
It’s tempting in a lot of cases to read the data sheet and determine that the product is good enough. But there are a lot of engineering and organizational challenges that aren’t written in the marketing documents.
Those challenges have to be searched for and social and technological tools must be developed to solve those challenges.
As an exercise in use of technology it looks easy but there’s an entire human and organizational side to it that gets lost in discussions on HN.
Not really. What we need is people not learning C (or any language) without also learning how writing it wrong causes defects. In my book (mentioned in the post) I have students using Valgrind and attempting to break their code starting at the 4th lesson. I also show them how and why to avoid defects in C.
Instead of saying "no new C", we should probably be approaching it with a two-pronged attack. First, tracking down bad educational material and making sure new C coders learn how to make safer C. Second, fixing the older code so that it is safe by default, rather than only in the context of the code it's written in.
But, yeah pipe dreams and all, so I just work on improving the educational material.
I'm terribly sorry you've never encountered an experienced developer who uses C or C++ before, or think we're non-existent, or that using extremes like "never" is a reasonable position instead of an incredibly terrible hasty generalization.
If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function.
Do you even understand how much mission and safety critical software is written in C? I think if you did you'd either have a constant panic attack (given your apparent belief that it's impossible to write "safe" C) or else have to adjust your world view a little bit.
Compiler these days optimise the code beyond human comprehension. Memory management libs, and what hardware does with your physical memory layout is inscrutable.
Register level vulnerabilities are very much black magic for anybody, but silicon maker itself.
Memory management libs used by any big C program add to complexity.
Fancy runtime pointer, and ROP sanitation libs fix some types of vulnerabilities, and add another.
And so, and so, and so.
I am a big proponent of C, but will not hide that C needs substantial education beyond just programming to use properly, and safely.
While C by itself is not safe, I would argue that no sane development environment uses C by itself. Over the decades of its production use dozens of tools have been developed that make it far safer: *grind suite, coverage tools, sanitizers, static analyzers, code formatters and so on. Those tools are external, otherwise they would make C slower. Something for something.
Frankly this is why I have trouble taking all this C advocacy seriously. Do managers really want their engineers using C? I understand how it can be pleasurable in the way that listening to vinyl is pleasureable. But my undersanding is that it takes years and years of experience to not make catastrophic errors in C. And that's a lot of risk.
A fairly moot point. Do you think most C developers can write safe C code? The 2 I've encountered in my short career basically have no idea what they're doing (which I suspect is partly why they stuck with C instead of exploring alternative languages).
Tools only created to solve the lack of safe constructs in C.
C made lots of sense in the context it was developed, but the world would be better if we had safer systems programming languages.
Valgrind, purify and friends are required to C, the same way Java requires IDEs, to improve language usability.
Have said this, the new trend in having static analysis tools integrated in the development process, like Clang, Eclipse CODA, Visual Studio's tools or HP Code Advisor, among others, can bring a bit more safety into C.
Note that ruining sanitizers in prod might be insecure. They're for development.
reply