From owner-freebsd-hackers Wed Jan 5 11: 5:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 9D7D4151C9 for ; Wed, 5 Jan 2000 11:05:39 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id LAA00966; Wed, 5 Jan 2000 11:05:19 -0800 (PST) To: Martin Cracauer Cc: Markus Holmberg , freebsd-hackers@FreeBSD.ORG Subject: Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD? In-reply-to: Your message of Wed, 05 Jan 2000 17:50:52 +0100. <20000105175051.A10840@cons.org> Date: Wed, 05 Jan 2000 11:05:19 -0800 Message-ID: <964.947099119@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000105175051.A10840@cons.org>, Martin Cracauer wrote: >In <91688.947090291@monkeys.com>, Ronald F. Guilmette wrote: >> ... >> Yes, the existing Mozilla code should be fixed to perform the range >> check in the manner that Martin Cracauer 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 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. Are there any IEEE exceptions for which traps MAY NOT be enabled or disabled?? The first sentence of IEEE 754 section 8 would seem to suggest that the answer is `no': ``A user should be able to request a trap an any of the five exceptions...'' >This case is a conversion of double -> int, it is not covered by >ieee754, but by ANSI C. Are you sure? My reading of IEEE 754 indicates that this situation is covered by *both* the ANSI C standard and also by IEEE 754. Specifically, IEEE 754, Section 7.1, subparagraph 7, seems to cover this exact case, and seems to mandate an IEEE invalid operation exception for this exact case, i.e. conversion of an IEEE floatint-point number to an int where the int is too small to hold the actual converted value. >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. Correct. And for the Mozilla programmers, the ANSI C rule is the only one of importance, because it effectively says that their code has a serious bug. But both rules (ANSI C and IEEE 754) _do_ apply. >Really, what else do you want? Its not that hard to understand really. I want: a) a world in which all Mozilla code conforms as strictly as possible to both the ANSI/ISO C standard and also as strictly as possible to the IEEE 754 standard, _and_ I want... b) a world in which FreeBSD conforms as closely as possible to (among other things) IEEE 754, e.g. with all IEEE FP traps disabled upon entry to main(). It is possible to have both without too much difficulty. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message