Java or C: Is One More Secure?

bluefoxlucid writes "Security has been a hot topic lately, and we've seen everything from changes to how memory is managed to compiler hardening to "secure" programming languages. Java is considered more secure than C in general; but this guy seems to disagree, and thinks hardening the system itself is the way to go. Are we really approaching the problem the wrong way, or is he just insane?"

Comments

Re:Not applicable

[lexarius]

Except that you can't do pointer math in Java. Java references are opaque and cannot be manipulated.

Here's a hint..

[Improv]

People who can't spell words in the English language like "aggravate" might not be the best people to look for deep and insightful attacks on what everybody else agrees on. I'm not saying that having good spelling would make his point any more valid, but it should at least be a rule of thumb for those who can't bother to think about his point on their own (as the poster of this article can't).

To get more into it, yes, the C runtime is smaller than the Java runtime, and there is a certain trustworthiness in having your code small. However, languages like C where the basic type system requires a lot of care to avoid bugs starts you off considerably behind just having a large runtime. In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.

Of course, in both cases, we're not really talking about the language being secure, we're talking about how likely it is that, given equivalent tasks, people using the different languages will end up writing secure code. To weigh that, we all use rules of thumb based on what we know causes errors -- he invokes bulk of code, but doesn't think about how the used code in that bulk will need to be written anyway and will be reused by every Java programmer. As I said before, I think a caveat-emptor type system is another major factor to be considered. Other (generally obvious) rules of thumb that go against this guy are left as an exercise for the reader.