Thanks for proving Bernstein right [LWN.net]

Thanks for proving Bernstein right

Posted Nov 8, 2007 19:49 UTC (Thu) by mrshiny (guest, #4266)
In reply to: Thanks for proving Bernstein right by i3839
Parent article: Daniel Bernstein: ten years of qmail security

The thing is, the common memory related bugs in C are handled in the JVM:

1. Reading/Writing invalid pointers: No way to use a pointer in Java without initializing it
to a valid object, no way to read past the end of an array, no way to read freed memory.
2. Double-free: No manual memory freeing
3. Memory leaks: Java memory leaks are more rare since unused objects are garbage collected.
You can still run into a problem where you have a cache of objects that is never cleared or
similar problems.

Sure, a bad programmer will write bad programs in Java where they don't check array sizes,
etc. But let's say they do: if their program overruns its array Java will halt the execution
(well, throw an exception). This prevents corrupting memory. Also you never have dangling
pointers so you don't have to worry about "corrupt" memory which was re-used by something
else.

These bugs are hard to track down in C because a program may work for a while until the memory
bugs appear. In Java it fails fast and safely. This means you can concentrate on the real
issues at hand. Your assertion that C code crashes quickly isn't totally accurate, it only
crashes quickly if you try to access memory that's not allocated... there's lots of other fun
ways to corrupt the memory before you crash. I'd have to say that, in terms of the "memory
corruption" bugs, Java fails more quickly and 100% more safely than C.

Considering that the world is full of bad programmers, I'd rather they program in Java than C.

to post comments

Let's take the argument further

Posted Nov 8, 2007 23:17 UTC (Thu) by man_ls (guest, #15091) [Link]

Imagine if some fellow said: "People should write only machine code (i.e. a string of hex values); after all, bad code is bad code, whatever its form, and in C you can still lose track of the execution point. Especially (but not limited to) if your code is full of GOTOs or it is very complex". The answer is obvious: don't use GOTOs and do not write complex code. Now imagine if you tried to have a meaningful discussion with a huge fan of machine code programming, who dismissed "modern" facilities such as pointers, variable names or structs. Or source code files. Or labels...

The real question (whatever die-hard C fans say) is: should we go even further, and create new languages with even more advanced facilities; or would it limit the expressivity of programmers too much? Where is that limit?