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 <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
Markus Holmberg | Give me UNIX or give me a typewriter.
[EMAIL PROTECTED] | http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
