[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Zeroes and infinities
Vincent Lefevre <vincent@xxxxxxxxxx> 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? :)
Ha, ha. Very funny.
There has been a consensus on the definition and semantics of
floating-point for at least the past 50 years, with even the areas
of variation being agreed. There is no such consensus on status
and error flagging mechanisms.
You will also find the definition of floating-point arithmetic and
indications of its expected semantics in the normative references
such as ISO/IEC 2382-1:1993, but the same is NOT true for 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).
I said that there was next to no language support for IEEE 754, and
that my statement applies to C99, too. The fact that it is such an
OPTION, and that the PROGRAMMER cannot choose that option, is very
relevant to that. In particular, no developer of portable code can
rely on it.
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.
Oh, no? I remember quite a lot of implementors doing that, quite
a long time back. It plays Old Hob with optimisation, validation
and many other aspects. There are a GREAT many people who say (and
can justify) that dynamic modes are a thoroughly bad idea, and the
ONLY modes should be static. This problem applies ONLY to dynamic
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.
That is no part of the language.
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).
That is your opinion. Many members of WG14 and many implementors
disagree.
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.
The former is correct. For the latter, see my previous remark.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679