Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!216.196.98.146.MISMATCH!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 22:29:10 -0500 Date: Thu, 07 Jul 2011 20:29:09 -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> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <04OdnShf8tQb5IvTnZ2dnUVZ_uWdnZ2d@posted.palinacquisition> Lines: 41 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 50.46.118.188 X-Trace: sv3-lkznHeFAxpUYdxp69q4mXtLzUyA6OwMTu9Vz+YAJ5ulc8eXD1Pno1Ef7NZ+9mcUwHFWRIngDuB5c+Zu!A4VDBFgwwdlKnkafp7lCGcaSDd8av9SEK/r4KYKLM9JCS20g27M4Iip3nA8/jmo3TlCdLW+RAnzN!1eriP6T42z6zY9LFalxX5M5h8Yeb/J1vM/bSIbHKDUA= 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: 3589 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5978 On 7/7/11 8:04 PM, Patricia Shanahan wrote: > On 7/7/2011 5:51 PM, Peter Duniho wrote: > .... >> 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. > > Not necessarily. I assumed a couple of decades ago that array index > checking would be impossibly inefficient, but it seems to work fine in > Java. The JIT compiler can in many cases remove bounds checking for arrays based on context. I suppose it could do the same sort of thing for overflow checking, which I think is what you're describing in the rest of the paragraph? (here: > I suspect that having integer range types would be a major help. > When I'm working out whether an int can overflow, I often think in terms > of the ranges of inputs to calculations. A compiler would be able to > tell that adding a digit to a digit always fits in the range [0,18]. ?) >> 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. > > The problem is "as needed". How does an automated tool tell the > difference between code that depends on the standard arithmetic and code > for which overflow detection is appropriate? It would rely on the user. It's only "automated" in the sense that it does the code rewriting automatically. It would still at a minimum have to be told which packages to apply the processing to. Pete