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.
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.
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.)
C itself is also scary. Most other languages provide at least run-time safety; some provide great compile-time safety. C providing neither and being the most popular language for system software is what is really scary.
I guess part of what is scary about C is that it gives you the illusion of a high-level language, but unless you know all UB by heart, you might accidentally start working in assembly.
Isn't there at least a flag that activates warnings for stuff like this? I tried -Wall in both clang and gcc and they didn't say jack shit.
What do modern C developers do these days? Arm themselves with expensive advanced static analysis tools to their teeth?
Why wouldn’t it be serious? C has been used to write safe, stable, & portable software for decades. Compiler warnings & static analysis tools have come a long way to preventing the vast majority of safety issues in (new) C projects.
Because C makes it really really easy to write test-free unsafe crap.
The list of bugs caused by use if C is genuinely ridiculous.
Now, I think there are ways to write robust C - I don't get many bugs now that I usually use AddressSanitizer and a static analyzer (the GCC one is really nice) but that simply isn't good enough any more for high-reliability code.
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.
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.
Indeed. It was designed to interact with C APIs directly from day 1 and they've made it more powerful fairly recently with Span<T> and Memory<T> (essentially "safe pointers").
You can literally develop entire applications in unsafe mode, with C's level of unsafety. Nobody does, but you could.
Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety.
Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.
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.
Um, no. C is a perfectly valid language and some of the best, most robust systems in the world are written in it (Linux, Git, etc.) Some languages are even built to run atop C (Cython.) Even the JVM deals with pointers, memory allocation issues, and such so you don't have to but it's still there!
So using a higher level or "safer" language isn't going to stop these kinds of problems.
I really have to disagree - I've seen and written a lot of perfectly safe C code. There are a lot of good reasons not to use C but that one's a rapdily expanding fallacy.
There is something missing from these discussions.
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.
reply