Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking Date: Thu, 07 Jul 2011 19:11:43 +0200 Organization: A noiseless patient Spider Lines: 51 Message-ID: References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <343576af-d714-462c-b96f-688bc6dfb0e2@e21g2000vbz.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Injection-Date: Thu, 7 Jul 2011 17:11:37 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="nqKdgi4oHX1eKtAL3rvGBQ"; logging-data="601"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/RTquGCB255s2jun0zjIG8" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: Cancel-Lock: sha1:CZGGOGhs5QVW7tCdu/2/2DQswBw= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5968 On 07/07/2011 13:54, Eric Sosman allegedly wrote: > On 7/7/2011 3:30 AM, rop rop wrote: >> On Jul 6, 11:32 pm, Tom Anderson wrote: >>> Modding the JVM is a non-starter for a few reasons... >> >> Hi Tom, >> Thanks for input. >> Could you just elaborate on this, please... what is the main-problem >> with actually patching the JVM? >> Why is it so hard? >> Without having looked into the source-code, this seems like the most >> straight-forward and robust way to do it... >> Is the code so hard to penetrate or what? > > The first thing that comes to mind is altering a JVM so it does > not behave as described in the Java Virtual Machine Specification > means you no longer have a JVM. Specifically, from section 2.4.2: > "The built-in integer operators do not indicate (positive or negative) > overflow in any way; they wrap around on overflow." For good or for > ill, that's a requirement all JVM implementations must satisfy. > > But, okay, you start with a JVM and alter it to produce a "KWN" > that behaves just like a JVM except in this one regard. Now a second > difficulty arises: You start running Java on the KWN, and almost at > once you get an arithmetic overflow exception. Investigating, you > find that it occurred in a hashCode() method that's computing the > time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and > a prime p. The overflow is entirely benign, yet "Hello".hashCode() > stops your program in its tracks. So now you need a way to distinguish > expected (benign) overflow from unanticipated (injurious) overflow -- > which means you need to alter not only the JVM but also Java. (Or maybe > you could do something with annotations; I'm not sure.) But the main > point is that all existing Java code expects overflow to wrap around, > and lots of that code actually relies on wraparound. > > Finally, you've got definitional problems to sort out. For > example, is there an overflow in `int value = (int)Long.LONG_MAX;'? > You need to put on your Language Legislator hat and think about it > before you can decide how your KWN should behave. > > Personally, I wish integer over- and under-flow would in fact > throw exceptions, and that the language had something like `unsigned' > to allow the programmer to suppress the exceptions when appropriate. > But that's a wish I don't expect to see fulfilled. > Not to mention the mess if it's an app you plan to distribute. -- DF. Determinism trumps correctness.