> Seems to me that such ranges are application specific and > therefore your problem, not the JVMs. You're describing a bug > in your code, due to failure to validate, not a bug in the > JVM which behaves exactly (and quite possibly provably) > according to its specification.
So you're saying that if I write code that fails to validate array bounds, and something bad happens, it is the compiler/runtime's fault, but if I write code that fails to validate integer bounds, it is the programmer's fault? That's a rather circular defense of JVMs, in which JVMs are praised for stopping the types of errors they choose to check, and also praised for not stopping the ones they could (but don't!). There *ARE* languages where integer variables have checked ranges, after all. The point (which too many people in this thread seem to be missing) is that there are lots of kinds of security relevant code flaws. Better tools, OSs, runtimes, etc catch more of them, but none catches all of them (for example, serious race conditions are still possible in almost all development styles and environments). The world is not going to be saved by managed code or JVMs or signed code or nonexecutable stacks or better education of developers or users. Finally being immune to classes of security flaws that were first used four decades ago is nice, but don't let it lull you into a false sense of security. Tim Hollebeek Research Scientist Teknowledge Corp _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
