Date: Fri, 24 Dec 1999 15:52:28 +0100 From: Markus Holmberg <saska@acc.umu.se> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, David Malone <dwmalone@maths.tcd.ie>, hackers@FreeBSD.ORG Subject: Re: SIGFPE on arithmetic overflow Message-ID: <19991224155228.A15007@shaka.acc.umu.se> In-Reply-To: <3246.945989187@monkeys.com>; from rfg@monkeys.com on Thu, Dec 23, 1999 at 02:46:27PM -0800 References: <59403.945979515@axl.noc.iafrica.com> <3246.945989187@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just a small addition to this thread: There seems to be a withstanding bug in Mozilla unique for the FreeBSD port, that seems to be quite related to this thread. It's about casting and SIGFPE's. Here's the link: http://bugzilla.mozilla.org/show_bug.cgi?id=9967 I don't know enough about these matters to be able to draw any conclusions, but anyone is of course welcome to take a look at the Mozilla bug, because it needs someone who knows this stuff. Markus On Thu, Dec 23, 1999 at 02:46:27PM -0800, Ronald F. Guilmette wrote: > > 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 -- Markus Holmberg | Give me UNIX or give me a typewriter. saska@acc.umu.se | http://www.freebsd.org 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?19991224155228.A15007>