Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: checking for overflow in C
Message-ID: <10256@smoke.BRL.MIL>
Date: 14 May 89 00:43:46 GMT
References: <13367@dartvax.Dartmouth.EDU> <1989May6.224226.22085@utzoo.uucp> <1989May9.183140.1770@utzoo.uucp> <8172@june.cs.washington.edu> <1079@atanasoff.cs.iastate.edu> <1989May12.154417.21344@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <1989May12.154417.21344@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>SIGFPE and friends unfortunately are *very* machine-specific, because you
>get signals only when the hardware feels like supplying them.

There is indeed a wide variety of arithmetic exception behavior.  Some
systems generate different exceptions for integer vs. floating overflow,
some generate the same exception, some generate exceptions in one case
but not the other, some generate exceptions only for limited classes of
arithmetic "problems", etc.

A few years ago, a system manager here, responding to naive "customer"
pressure to generate floating exceptions on our Gould PN series machines,
modified the run-time start-off module to enable exceptions.  What he
didn't appreciate was that the C compiler generated code that required
integer overflow to be ignored, and 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.