Ok, Folks,
first of all I apologize for getting carried away and proposing
replacement functions that incompletely implemented the requested
behaviour. The equivalent macro with range check is 40% slower (why
isn't the MS VC++ specific test case #unifdef'ed for other
platforms?).
Then, I am not against disabling those exceptions by default that have
meaningful results when masked. That are all exceptions that would (if
not trapped) result in a floating point value with meaningful
semantics: overflow, underflow and divide-by zero.
But I am against disabling "invalid operation" by default, because the
most often cause of this exception is the case discussed here: A
conversion of a too big FP value to an int where it doesn't fit.
The result of this operation is at the very least (depending on the C
standard in use) an unspecified integer and must not be used. Only in
rare cases the programmer knew what he/she did and ignored the result
of the operation just carried out. I agree that this Mozilla issue is
such a case, the value is supposed to be ignored. But the macro's
interface doesn't enforce it. If the macro is that often used in
mozilla, I bet I can point out cases where it isn't ignored.
Regarding ANSI C:
- ANSI C 89 makes it clear that the behaviour is unspecified and that
anything may happen and that this macro may not work. An optimizing
C89 conforming compiler may chance this code in a way that breaks
the macro.
- Waldemar is correct that C99 changes the "undefined behaviour" to
"the result is an unspecified value". In that case the Mozilla macro
is quaranteed to work. However, neither gcc nor FreeBSD claim to be
C99 conformant.
When thinking about default FP exceptions, it all comes down to the
ratio of cases where one exceptions raised a false alarm or where a
serious error was caught.
In the case of "invalid operation" that ratio is overwhelming in favor
of "real" alarms, and in most cases of false alarm (like this Mozilla
macro) it points out constructions that need to used with extreme
caution.
Again: Here we have a programmer that writes a really clever macro
that messes with FPU conversions. He knows C89 and C99 enough to point
out the relative parts. Code that is so specifically written for one
FPU behaviour in mind should set the FPU exception mask. If only to
document that it knows what it is doing.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
