|
|
Log in / Subscribe / Register

Thanks for proving Bernstein right

Thanks for proving Bernstein right

Posted Nov 4, 2007 18:04 UTC (Sun) by i3839 (guest, #31386)
In reply to: Thanks for proving Bernstein right by MattPerry
Parent article: Daniel Bernstein: ten years of qmail security

If you read my previous post, I'm not baffled by that. My original point was that moving those
people to something else like Java only produces buggy Java code instead and doesn't solve the
problem of buggy code. You could even say that C has an advantage here because their code
won't work in the first place and would crash all over the place. ;-)

All right, that's perhaps a step too far, but it is indeed easier to make a big mess in C.
With Java you get "works for me, bug must be in your part"-code.


to post comments

Thanks for proving Bernstein right

Posted Nov 4, 2007 22:43 UTC (Sun) by ms (subscriber, #41272) [Link]

The only way to help such programmers is to use languages which do proof carrying code. Then
you /know/ that if it type checks, some proof holds about the program. Whether or not that
proof means anything to you is for you to decide.

Thanks for proving Bernstein right

Posted Nov 8, 2007 19:49 UTC (Thu) by mrshiny (guest, #4266) [Link] (1 responses)

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.

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?


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds