Date: Thu, 23 Dec 1999 14:46:27 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: David Malone <dwmalone@maths.tcd.ie>, hackers@FreeBSD.ORG Subject: Re: SIGFPE on arithmetic overflow Message-ID: <3246.945989187@monkeys.com> In-Reply-To: Your message of Thu, 23 Dec 1999 22:05:15 %2B0200. <59403.945979515@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <59403.945979515@axl.noc.iafrica.com>, you wrote: > > >On Thu, 23 Dec 1999 17:14:55 GMT, David Malone wrote: > >> Try adding a fpsetmask(fpgetmask()&(~FP_X_OFL)); before the calculation >> and see what happens. > >It still bombs, although fpsetmask(0) does the trick. I'm really >interested in hearing what causes the difference in behaviour. Sorry, I breezed past the first part of this thread too quickly, so I forgot which OS is doing what. However let me say that I do still have a copy of the IEEE floating point standard around here, and if anybody needs me to, I'll be happy to look stuff up in it, and/or to cite chapter and verse. The bottom line, I think, is that the IEEE FP standard talks about two things of interest here... exceptions and traps. An exception is just some condition that probably only arises infrequently (e.g. overflow, divide by zero, and other such stuff). An exception may or may not cause a trap. A trap is one possible response to an exception, and can be thought of as being essentially the same sort of thing as a (non-blocked) UNIX signal. Anyway, to bring this back to the topic at hand, the relevant quote from IEEE Std 754-1985 (Section 7, paragraph 1) is: ``The default response to an exception shall be to proceed without a trap.'' In other words, for a conforming implementation of IEEE 754, unless you explicitly override the default behavior (e.g. with a call to fpsetmask) exceptions (including FP overflow) SHOULD NOT cause a trap. I should say however that back when I was doing compiler testing for a living... a few eons ago... this was something that a lot of implementa- tions did seem to screw up.... Many compiler/library/OS combinations would invoke main() with one or more of the IEEE FP exceptions set to cause a trap/signal (in violation of IEEE 754). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3246.945989187>