Date: Wed, 5 Jan 2000 09:50:02 +0100 From: Martin Cracauer <cracauer@cons.org> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD? Message-ID: <20000105095002.B8100@cons.org> In-Reply-To: <87632.947017515@monkeys.com>; from rfg@monkeys.com on Tue, Jan 04, 2000 at 12:25:15PM -0800 References: <20000104121459.A8959@cons.org> <87632.947017515@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <87632.947017515@monkeys.com>, Ronald F. Guilmette wrote: > > In message <20000104121459.A8959@cons.org>, > Martin Cracauer <cracauer@cons.org> wrote: > > >Hence it is good to trap this and it is a bug in Mozilla, period. > >... > >I think we might discuss lowing the traps so that the softer > >exceptions are disabled. But most cases where people cry about > >FreeBSD's behaviour are serious errors like the one in mozilla, so we > >won't gain much. > > I agree that it appears that the Mozilla code had a serious bug/flaw, > and that having the FP traps enabled caused that fact to become > apparent. > > But the issue for me is still one of standards conformance. Regardless of > how helpful enabled FP traps may be, on occasion, for certain programs > and/or certain programmers, the IEEE 754 standard is pretty darn clear > and unambiguous regarding what the default setting should be, i.e. all > traps disabled. You mix up two things: 1) "Real" floating point arithmetic between floating types. 2) Conversion of floating point types to integer. The authority on the latter issue is ANSI C, not ieee754. ANSI C 89 states in 6.2.1.3 explicitly, that "if the value of the integral part cannot be represented by the integral type, the behaviour is undefined". ANSI C 99 (WG14/N869 Committee Draft -- January 18, 1999) has the same sentense in 6.3.1.4. Note that "undefined behaviour" in ANSI C means that anything can happen. There is no quarantee that the code in question even behaves as if variable i was filled with any integer. But the Mozilla macro relies on exactly that, hence it does not conform to the standard. It also doesn't reach its speedup goal, see my other message. Regarding the "real" (non-converting) floating point exceptions: As I stated earlier, that is a different mattter since they are covered by well-defined behaviour when they are masked. But I wonder whether turning off the harmless exceptions, but leaving on the harmfull wouldn't confuse people even further, since certain other OSes turn off everything and we would look like them on first sight and then turn up with surprises later. 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?20000105095002.B8100>