Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!postnews.google.com!ct4g2000vbb.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 10:21:44 -0700 (PDT) Organization: http://groups.google.com Lines: 43 Message-ID: <1ca84a18-e879-4249-a9e2-cea8c1ad7b92@ct4g2000vbb.googlegroups.com> 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 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1310491305 9038 127.0.0.1 (12 Jul 2011 17:21:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jul 2011 17:21:45 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: ct4g2000vbb.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:6125 comp.lang.c:8180 On 12 Jul., 14:25, Malcolm McLean wrote: > On Jul 12, 2:17=A0pm, tm wrote:> On 12 Jul., 12:33= , "BartC" wrote: > > > > The a+b overflows, but then what? You can't then magically switch ove= r 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. > > The problem is that 32 bit ints are large enough to count most things, > but not all. > > You can't give a different 32-bit integer to everyone in the world, > for example, nor to all the bytes of RAM you might reasonably have in > your desktop computer. > > 64 bit ints solve most of these problems, they can count the vast > majority of things we need to count. When CPUs moved from 16 to 32 bit integers the argumentation was similar. Using 64 bit ints only shifts the problem, but does NOT solve it. Only overflow detection and unlimited precision integers can solve it. 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.