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.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 07 Jul 2011 22:04:59 -0500
Date: Thu, 07 Jul 2011 20:04:56 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
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> <CpmdnZ2c6KsSI4jTnZ2dnUVZ_jydnZ2d@posted.palinacquisition> <wZCdnWNqDO0pe4jTnZ2dnUVZ_v2dnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition>
In-Reply-To: <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <pPqdnbD2qr5G7ovTnZ2dnUVZ_qednZ2d@earthlink.com>
Lines: 30
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 70.230.196.78
X-Trace: sv3-tuPhu2odrFWasB97yeKMwpBARcZA5PHHJIa4FPntP36QiLzc+byFGC+MmwjFjuWTvTcnoRDetFeMxdg!nVJyfFZ//wJENWfPqnO6/4I1naBOVTMKkbj8W78/MNWWZ2j42af1zAmNYJIp2YK7uwDnKtHiM3EW!+tKLYsgYeWQ5H9Ool8tAsuQ+uz4RxVBPvsMu1APBHr4m0A==
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: 2885
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5977

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. 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?

Patricia