C Safety Debate

It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. Even when people pay careful attention, problems arise: consider the various 0days in sudo. C isn't simple: it's simplistic: its apparent simplicity comes from shifting the burden of safety from compilers to humans. Consequently, we spend trillions of dollars on dealing with the consequences of security vulnerabilities, most of which wouldn't exist if programmers used me

Sounds like you're not really in touch with the real word. C has many benefits and it is super practical. Yes, you can write unsafe code, but safety isn't always your #1 priority. There are also tools you can use to identify issues, which will mitigate risks.

C is okay except safety. Look at the CVE lists and they are still full of memory errors and it’s 2024.The problem isn’t that good programmers can’t write good C code, though anyone can make a mistake. The problem is what happens as code ages, is worked on by other people, gets PRs merged, and so on. Bugs creep in and in an unsafe language nothing catches them.C also makes string processing hellish, but that could be fixed with libraries and isn’t necessarily the fault of the language.

Not at all.There is a world between every single string, array and numeric operation being a possible source of memory corruption and being forced to explicitly write unsafe code.I have been using mostly safe languages since the 80's.They only get in the way of cowboy programming, which is a very good thing for anyone that praises quality in software development.C would no longer be around if companies got properly sued for each CVE exploit.

That's basically how I see it. I can even trace many CVE's and crashes to C's safety issues. Currently, CompSci people are building reliable and secure HW for us but existing C code is difficult to integrate. Had it been Oberon or something, it would be a lot easier as the developers don't meddle directly with bits and memory as much.

There are plenty of other bugs causing CVEs, but there are certainly a lot caused by memory issues. I personally believe that C needs a safe mode, but also with existing tools (static analysis, sanitizers, etc.) one can improve things a lot. It is a bit unfair to compare billions of lines of old C code to newly written code in other languages. It would be interesting to compare modern C with modern tools to other languages. And, of course, all those billions of lines of old C code will contin

Everybody makes mistakes, no matter how confident they are in C. And while there are numerous things written in C, there is also a continuous stream of bugs and vulnerabilities as well.That’s not to say that other languages are perfect, but there are much safer options that are still very fast, such as Rust, or even C# or Java.

Writing secure software in C is just next to impossible. Memory corruption, arbitrary pointers, deep magic. Even pure assembly is more secure, as everything is explicit and well-defined there. There are lots of safer languages than C, and performance is not everything.

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.

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.