[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Zeroes and infinities
On 2007-06-03 13:13:48 +0100, Nick Maclaren wrote:
The whole of 7.6 <fenv.h> is specified for all C99 implementations,
but actually specifies only the syntax and leaves the semantics
undefined - unless Annex F is in force.
Just like floating-point arithmetic. C99 doesn't define its behavior,
"unless Annex F is in force". So, would you say that C99 can't support
floating-point arithmetic, just like you said that it can't support
the IEEE-754 flags? :)
Annex F is optional (at the IMPLEMENTOR'S whim), and is specified
to set __STD_IEC_559__ to 1 if it is in force.
Yes, but I recall that we are in the stds-754 list. So, we should
assume C99 with IEEE-754 support (in both the C99 sense and the
IEEE-754 sense).
But it, in turn, is specified to set the flags correctly only if the
programmer obeys certain rules, which include:
Always setting #pragma STDC FENV_ACCESS to on
Never setting #pragma STDC FP_CONTRACT to on
I'd say: setting #pragma STDC FP_CONTRACT to off, as it can be on by
default.
These two points are not impossible and are easy to satisfy.
Never relying on a flag over any standard library call (except
for <fenv.h> and <math.h>) - yes, that includes abs from <stdlib.h>
Never calling a library function with any mode set to a non-
default value
This isn't new. This is already a known problem when changing the
rounding mode. But no-one has complained here on the fact that
IEEE 754 provides different rounding modes.
Never calling any external library - even one guaranteed to be in
conforming C99
Never using complex arithmetic
You forgot the main point: the quality of implementations. The C
implementation and external libraries can document what they do
with rounding modes and flags.
It is also unclear that, even if an implementation sets __STD_IEC_559__
to 1, it need provide all of the relevant macros. That is generally
assumed, but the standard doesn't require it explicitly.
If the flag exists, the implementation should provide the macro.
If it doesn't provide it, this can be regarded as a bug (whether
the C standard requires it or not).
But, even given all of those restrictions, there was a considerable
and inconclusive debate over whether 6.5 paragraph 5 overrode the
specifications in Annex F or the converse. Here it is:
[#5] If an exceptional condition occurs during the
evaluation of an expression (that is, if the result is not
mathematically defined or not in the range of representable
values for its type), the behavior is undefined.
which doesn't mean that an implementation can't define it. And an
implementation supporting IEEE 754 should define it.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)