Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.palinacquisition!news.posted.palinacquisition.POSTED!not-for-mail NNTP-Posting-Date: Thu, 07 Jul 2011 19:51:07 -0500 Date: Thu, 07 Jul 2011 17:51:06 -0700 From: Peter Duniho User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> Lines: 80 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 50.46.118.188 X-Trace: sv3-aZpGlnuUEaJ/o7vyEx/W7D+zdg1/nIIW0p2F5ULSDqGOi8CoclYxvFUAJfxvErsBgKfUJglBkpUqm7C!mQY5K1yjxuFZT2mX5KBop6qE5n3T1gn0y2YWEFa7xG5wZ63ku5ZGtj0pahwNAfqF4jI0lzAMBOo1!CnxnOO0HN9PJt5/9Obwrvl5H4eyB/MDPKHls9vWKdkc= X-Complaints-To: abuse@iinet.com X-DMCA-Complaints-To: abuse@iinet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5438 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5976 On 7/7/11 10:02 AM, Patricia Shanahan wrote: > On 7/7/2011 7:11 AM, Peter Duniho wrote: >> On 7/6/11 10:16 AM, Patricia Shanahan wrote: >>> On 7/6/2011 8:35 AM, rop rop wrote: >>>> Hi, >>>> >>>> If I want to have arithmetic-overflow checking in all parts of an >>>> application, >>>> what is the most practical, simple, efficient way to achieve this? >>> >>> Write the application in Ada. >> >> Or use C#, which has the same feature, but is a lot more like Java >> otherwise. >> >> That said, I suspect Tom's guess is correct and a language-change just >> to achieve this goal isn't going to be the practical choice. > > Like most design decisions, it is a trade-off. If Tom *needs* overflow > checking, the most practical, simple, efficient way to achieve it is to > use a language that is designed to support overflow checking. To be clear, I don't think _Tom_ needs or doesn't need this. He was simply replying to the OP. > If he merely *wants* overflow checking, the best choice may be to stick > to Java and drop general overflow checking. That does not prevent having > e.g. a BigInteger subclass that takes a range as a constructor parameter > and does overflow checking against that range. I don't disagree with that. In fact, I'm skeptical that in any program it really makes sense to apply overflow checking to _every_ computation, even not counting the issues that have already been pointed out wrt the JDK itself and other libraries which rely on the lack of it. For example, does every integral "for" loop _really_ need the index increment operation to be checked for overflow? Seems unlikely to me. While the discussion has been interesting, I can't help but feel that the original question is fundamentally flawed. The answers are mostly academic, as it's unlikely anyone really ought to be trying to approach the problem in this way in the first place. > I have not yet seen an option for getting general overflow checking in > Java, without getting false hits on code that depends on the JLS > specified arithmetic behavior, that is at all practical, simple, or > efficient. Well, I think Tom's suggestion of some sort of automatic code-rewriter _could_ be the best solution in _certain_ scenarios. Such an implementation could be applied selectively to specific code. I would not worry about the "simple" or "efficient" criteria. IMHO, if one is deciding to apply overflow checking to every computation, one has already abandoned the hope of efficiency. And "simple" is relative; if the requirement for checking is absolute, no solution is going to pass the "simple" bar for all programs, especially non-trivial ones. In a very large code base, where one literally wants to apply checking to all of that base, either a rewrite in another language or trying to track down every possible place where one can replace a built-in type with a custom overflow-checking type could very well be more costly and complex a solution as simply writing a generalized tool that inserts overflow checking everywhere as needed. I'm not really that big a fan of code-rewriting, mind you. Debugging can be hard enough without having to deal with live code that's completely different from the original source code, and of course bugs in the rewriter itself can manifest as strange, hard-to-debug problems in the rewritten program. But when one is talking about relative cost of implementation, there may well be scenarios where code-rewriting has the lowest cost compared to other choices. In terms of practicality, that would make it a win. Frankly, as long as the discussion is purely hypothetical (as it is now), I don't see how anyone can claim with 100% certainty the broad superiority or inferiority of any given solution. It's too dependent on the specifics of whatever real-world scenario is at hand. Pete