It's basically impossible to write safe code in C. Surely that makes it pretty damn poor at what it does?
Especially since system code is the place where safety matters most.
Especially since system code is the place where safety matters most.
If memory safety ever becomes a practically solved problem (e.g. somebody's running an OpenBSD-style count of how many days since a new memory bug popped up and it gets past, I don't know, hate to be greedy, how about 3?), then I'll be merrily banging away on the other aspects.
and it's not like higher level languages are significantly better in this regard.
The last time I accidentally executed injected code due to a free error or buggy bounds check in the non-C parts of Python, or Ruby, or Lisp, or Erlang was ... well, never.
And no, the fact that C underlies all these languages isn't a testimony to the adequacy of its security features.
if C was so insecure, you would expect that interpreting python would be just as "insecure" as writing C.
1) A lot of "Python" security vulnerabilities are caused by "C"-problems (overflow errors, etc). [1] and [2] are a couple from this year.
2) You'd expect interpreting python to be more secure than C because the interpreter acts as a filter over input reducing the attack surface, meaning that potentially vulnerable paths are minimised are better tested than if an entire program was in C.
Look, I know lots of people like you think that C isn't that hard to get secure code from. But if you were correct, we wouldn't be living in the security cesspool of memory bugs we are now.
However programs written in C may or may not be insecure.
Of those programs you would expect a compiler or interpreter, that has been tested in the wild on millions of programs, and so you are more likely to find the security bugs. Also we hope these programs are written by very talented engineers.
On the other hand Joe Enterprise hacking up a greenfield web service for the first time in C ... more likely to have security bugs.
If Joe Enterprise moves from C to Java. Less likely to have security bugs.
Now, what is the combined LOC for all Python code that uses the CPython interpreter (and those LOC are in a higher-level language).
Now compare that to the amount of C code that that would amount to if all of that code was written (or, tried to be written) in C instead.
And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.
Of course it's possible. If your issue is memory checking you can use mudflap or valgrind.
> Surely that makes it pretty damn poor at what it does?
No, it surely does not.
> Especially since system code is the place where safety matters most.
And yet somehow they manage. The security issues you find in system code are not things that would be helped by range checking.
It might be theoretically possible but in practice nobody has managed to do so with any non-trivial application.
Any further errors will not be fixed by any supposed "safe" language either.
Imagining that another language will make a difference is a mistake. It will not.
Only if you can be sure you have touched all the interesting portions of input-space. Ideally your tests are doing this, but wherever your tests miss aren't covered by valgrind or mudflap but are covered by a change of language. That's a part of what's meant by safe. It's not that it's impossible to write correct code in an unsafe language. It's that it's difficult to impossible to verify that you have written correct code. I'm very willing to include available tools in that calculation, but valgrind and mudflap (while tremendously useful) cannot give guarantees.
And in fact if someone used valgrind and fixed any errors (which plenty of people have done successfully) that completely disproves him.
He should retract his false statement due to evidence against it.
People have unquestionably used Valgrind to find errors, in trivial and nontrivial applications. The question here is whether the result is "safe code". It may be, but the parent does not seem to be speaking to that question, hence my attempt at clarification.
> ... the result is "safe code". It may be, but the parent does not seem to be speaking to that question ...
Here we differ. The ability to successfully run valgrind (and presumably remove all errors) does actually speak to the question, and it answers that the result is in fact safe code.
It is not necessary for the compiler to assure safe code, it's perfectly possible to do it with an external tool. And as a result C is a safe language as long as you use both tools.
Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.
uKernel in C , smaller codebase.
Drivers in (everything, possibly Ocaml/Lua/Common Lisp/C++)
Os in everything.
The Linux kernel is not written in C but in a DSL that there is not yet a compiler to generate C. This is the same like Enlightment Object System and GObject.
moreover drivers should be written in a DSl language (Termite-like) that supports concurrency and provided by spec writters as an appendix.
The driver is two parts. The OS adaptation Layer and a Formal description of modus Operandis.
Consider USB, normally the spec provides an implementtion i a DSL that "compiles" to the prose.
One can mechanically check for invariants and properties and compile to an OS package.
I think it is possible. Packages for example could describe transports
e.g. module BT uses an Ocaml-like interface for transport that can have various implementations like USB transport.
But all could be written in the same DSL.
Of course Kernel developers are allergic to memory management. Rust/Ocaml/D are the anti-histamine.
Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.