Date: Wed, 5 Jan 2000 17:50:52 +0100 From: Martin Cracauer <cracauer@cons.org> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: Martin Cracauer <cracauer@cons.org>, Markus Holmberg <saska@acc.umu.se>, freebsd-hackers@FreeBSD.ORG Subject: Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD? Message-ID: <20000105175051.A10840@cons.org> In-Reply-To: <91688.947090291@monkeys.com>; from rfg@monkeys.com on Wed, Jan 05, 2000 at 08:38:11AM -0800 References: <20000105092356.A8100@cons.org> <91688.947090291@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <91688.947090291@monkeys.com>, Ronald F. Guilmette wrote:
>
> >The alternative to this hack is a normal range check...
> >...
> >static inline int cra_is_int(const double d, int *const i)
> >{
> > if (d <= (double)INT_MAX && d >= (double)INT_MIN) {
> > *i = (int)d;
> > return 1;
> > } else
> > return 0;
> >}
>
> The function shown above is indeed the correct solution/approach for
> what Mozilla is trying to do here, for the reasons cited above.
>
> But having said that, I also want to reiterate what I said before...
>
> Yes, the existing Mozilla code should be fixed to perform the range
> check in the manner that Martin Cracauer <cracauer@cons.org> has
> shown above. However the can-of-worms opened up by this whole
> thread/discussion has revealed *two* bugs... one in the Mozilla
> code (which Martin Cracauer <cracauer@cons.org> has correctly
> described, diagnosed, and provided a solution for) and also, there
> is still that annoying little deviation from the IEEE FP standard
> that results from FreeBSD's failure to disable all IEEE FP traps
> upon entry to main.
>
> _Both_ bugs should be fixed.
As I said in the other message: This case is not covered by the IEEE
exceptions that may be disabled.
This case is a conversion of double -> int, it is not covered by
ieee754, but by ANSI C. And the ANSI C standard has its own paragraph
for exactly this case and its own sentense that if the the double is
out of range the behaviour is undefined.
Really, what else do you want? The issue would be different if we'd
talk about float devision by zero or a pure FP overflow, but we don't.
We don't talk floating point arthmetic here, we talk floating point
conversion and a case that is directly covered by ANSI C.
> P.S. Actually, although Martin Cracauer's suggested replacement for
> the existing Mozilla code is certainly better than what Mozilla is
> using now, it may perhaps need to be slightly augmented with an
> additional check to see if the value of `d' is a NaN prior to per-
> forming the range check. But I'm not even sure about that. I'd
> have to go and dredge my copy of IEEE 754 out of my files again to
> find out what the results of <= and >= are in cases where one of
> the operands is a NaN. I think however that those operations are
> perhaps required to return False in that case, in which case Martin
> Cracauer's suggested Mozilla replacement code is just fine as it is.
I test of >= and <= against NaN always returns nil.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
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?20000105175051.A10840>