Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.lang.c
Subject: Re: checking for overflow in C
Message-ID: <29093@ucbvax.BERKELEY.EDU>
Date: 7 May 89 23:56:37 GMT
References: <13367@dartvax.Dartmouth.EDU> <10218@smoke.BRL.MIL>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU.UUCP (Jim Shankland)
Organization: University of California, Berkeley
Lines: 25

In article <10218@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <13367@dartvax.Dartmouth.EDU> shallit@eleazar.dartmouth.edu (Jeffrey Shallit) writes:
>>... enlighten me about the officially approved way of checking overflow when
>>multiplying two integers.
>...
>You're looking for tactics when what is needed is better strategy.
>How did you get your algorithm into the state where an overflow is
>even possible?  Sounds to me like the algorithm needs to be better
>engineered.

I can think of lots of cases where the operands of an arithmetic operation
aren't known until run-time.  The only way to ensure that the operation
won't overflow is to perform some check on the operands, which is exactly
what he was inquiring about.  I don't know how else he might "better
engineer" his algorithm to avoid the problem.

I understand the reasons for C's overflow semantics (or lack of them, if
you will).  Nonetheless, while it's not a problem most of the time,
when it is a problem, it's a big one.  Operations like multiplication
end up becoming a subroutine -- often one written in assembler.

Jim Shankland
jas@ernie.berkeley.edu

"Blame it on the lies that killed us, blame it on the truth that ran us down"