Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!ulysses!ggs
From: ggs@ulysses.homer.nj.att.com (Griff Smith)
Newsgroups: comp.lang.c
Subject: Re: checking for overflow in C
Summary: machines do what they want to
Message-ID: <11538@ulysses.homer.nj.att.com>
Date: 17 May 89 20:14:19 GMT
References: <13367@dartvax.Dartmouth.EDU> <1989May6.224226.22085@utzoo.uucp> <472@chem.ucsd.EDU>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 34

In article <472@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes:
> In article <10256@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
> >... the Gould hardware tied integer
> >and floating exceptions to the same enable bit.  Consequently non-floating
> >applications started dying due to unexpected SIGFPEs.  We were not amused.
> 
> Aren't unsigned int operations guaranteed not to generate exceptions?

It depends on the architecture.  On many machines there is no
difference between unsigned integer arithmetic and signed integer
arithmetic.  After doing the operation, the program tests different
bits in the condition code depending on the type.

> It seems like the C compiler could/should have done things differently.

It may have no choice.  After doing an `add' that causes overflow, it's
a bit late to tell the hardware that you were doing an unsigned add.
Preventing the overflow is often an expensive operation.

As an example of how gross it can get, consider how DEC's TOPS-10 OS
separated integer and floating exceptions: if either condition was enabled,
the processor generated a trap to the kernel.  The kernel then tested
the `enable' bits for both conditions, and quietly returned control to
the user program if the trap wasn't enabled.  As you might imagine, this 
had strange effects on execution time.

> -- 
> || Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu

-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs@ulysses.att.com