In message <[EMAIL PROTECTED]>,
Martin Cracauer <[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote:
>> ...
>> 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.
I agress with your assertions regarding the C standard completely, but...
I don't think that I mixed anything up.
There is a bug in the Mozilla code (for the reasons you mentioned) _and_
also a bug in FreeBSD's conformance to IEEE 754 (or lack thereof).
Didn't I say that?
-- rfg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message