In message <[EMAIL PROTECTED]>,
Martin Cracauer <[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote:
>> ...
>> Yes, the existing Mozilla code should be fixed to perform the range
>> check in the manner that Martin Cracauer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
