Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit3.readnews.com!postnews.google.com!fv14g2000vbb.googlegroups.com!not-for-mail From: tm Newsgroups: comp.lang.java.programmer,comp.lang.c Subject: Re: Arithmetic overflow checking Date: Tue, 12 Jul 2011 05:24:33 -0700 (PDT) Organization: http://groups.google.com Lines: 71 Message-ID: References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> <3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com> <289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com> NNTP-Posting-Host: 84.112.82.23 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1310473562 24488 127.0.0.1 (12 Jul 2011 12:26:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jul 2011 12:26:02 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: fv14g2000vbb.googlegroups.com; posting-host=84.112.82.23; posting-account=269_QwoAAADSifhJt6OVa6bEjZR2ZMUB User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.18) Gecko/20110615 Ubuntu/10.10 (maverick) Firefox/3.6.18,gzip(gfe) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6118 comp.lang.c:8172 On 12 Jul., 13:33, "BartC" wrote: > "tm" wrote in message > > news:a642c317-92bf-47a3-995a-2839d17c98ba@cq10g2000vbb.googlegroups.com... > > > > > On 12 Jul., 12:33, "BartC" wrote: > >> "tm" wrote in message > > >>news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com... > > >> > And popular CPUs, which do detect integer overflow, do not > >> > trigger an interupt. This makes zero overhead overflow > >> > detection impossible. > > >> > So software suffers because hardware / CPU designers want > >> > to save a transistor... > >> int a,b,c; > > >> c=a+b; > > >> The a+b overflows, but then what? You can't then magically switch over > >> to: > > >> long long int a,b,c; > > > No, when a+b overflows, there is a bug in the program. > > The purpose of overflow detection is NOT support for > > unlimited precision integers. When the programmer thinks, > > that all his computations will fit in an int, he can use > > it (for performance or other reasons). In this case > > he probably wants to know when his approach was wrong. > > > Most programmers want correct results, or the > > information that something went wrong. Reasons where > > wrong results are acceptable should be left out from > > this discussion. > > OK, so it's for debugging purposes. Not alone. Arithmetic overflow checking should be also done in production. Like you want to know also when a production system does division by zero, dereferences NULL, accesses memory outside the process (SEGV), accesses array elements outside of an array or does other illegal things. For that reason I am interested in hardware support to do (near) zero overhead arithmetic overflow detection. > In this case, any overhead (of extra > instructions to check flags and interrupt or whatever) is less important, > and can be (and needs to be) optional. Sometimes extra instructions are necessary, to do some checks. But, except for rare cases, reasonable checks should be done in a production system also. The philosophy: No checks in a production system should be a thing of the past. Greetings Thomas Mertes -- Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows.