Slashdot Mirror
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?"
By design C allows you to access memory at your own descretion. I beleive Java does also (It's been a while), which means neither is a 'secure' programing language. This would be like asking if Fords or Chevys are safer because one uses tig welding and the other uses mig welding. It completely matters on how the code is used. You can write your own memory editor in C (and I beleive Java). Which would make them fundamentally unsecure. C has the advantage that you have to write your own code, so you can make sure it is bug and security flaw free (cha right, and monkeys might fly from my ass!) where as Java comes with libraries. No need to recreate the string. Which saves you tons of dev time, but now you depend on someone else's code review. With that in mind, I'd say Java has a slight edge, just because more people are testing the Java libraries then your custom made objects.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
TFA talks about C being just as secure with protection bits, claiming that use of stack-protection stuff is going to increase programmer and company awareness and willingness to fix bugs. They can fix the bugs, it's going to make it easier, but the inverse is what will happen. Instead of better software coming out, less time is spent on fixing that kind of bugs "since the protector will catch it anyway". Why bother fixing something that doesn't crash the program?
On the other hand, if you convert all these soft errors to hard errors (instead of a program doing something softly off-balance to a rigorous crash) they'll be fixed faster. Yet still, just teach the programmers to program.
Oh, and please do give all books about programming you have left to EA. They appear to be hiring kids between 12 and 16 since they're cheaper, judging by the quality of their software. I can't even run NFS3 in opengl mode since my video card isn't supported... no, the pre-pre-pre-pre-pre-predecessor was.
This more pertains to yesterday's article on performance, but it relates to Java in general.
I see lots of articles saying how garbage collection prevents memory leaks and provides security improvements. That is a slight misunderstanding: The automatic memory management is what makes it secure, not the garbage collection. The garbage collector is merely HOW the memory is freed. If Java eliminated the garbage collector and freed the memory immediately the language would be equally secure. What matters is that you don't have access to pointers.
For example, take Visual Basic 6: This language does not have garbage collection, but it is about as safe as Java. It frees memory/objects that aren't used, uses bounds checking, doesn't allow bad casts, and doesn't use pointers. The only time VB6 is a problem is when you call an outside library (which is the same problem you have in Java). So it isn't the garbage collector that matters.
Inherently, a language with access to pointers is always going to be less secure than a language that does not have them, and uses automatic memory management. None of the security enhancements to the compiler can change code that assigns a pointer to the wrong object and overwrites the memory for it. None of them can prevent a bad cast from screwing things up.
I switched to Perl because there were no memory allocation problems like this.
The fact that you were using C to solve a problem that apparently could have been solved in Perl suggests a problem right there.
C has its uses when you have particular requirements.