Questions about NCEG
Doug Gwyn
gwyn at smoke.BRL.MIL
Wed May 30 21:07:10 AEST 1990
In article <1990May29.193451.6533 at twinsun.com> eggert at twinsun.com (Paul Eggert) writes:
>|(1) If you stick to the letter of the IEEE 754 and IEEE 854 standards,
>| conversion of numeric literals from decimal to binary (or possibly,
>| in the case of 854, to internal decimal) is a *run* *time* operation,
>No C compiler that I know of does this. Does this mean that no C compiler can
>claim conformance to both IEEE 754 and ANSI C? I fear that if we ask either
>standards committee for a ruling, they'll refer us to the other committee.
Fear what you will. X3J11 certainly did consider this and other floating-
point issues. The C standard supports use of IEEE floating-point. However,
it doesn't require that access be granted to all features of it, just the
consistent subset chosen for the C implementation. Use of extensions that
access such features as selection of rounding mode render a program not
strictly conforming, so the implementation is at liberty to give the
expected meaning to them.
>There are ways to say the IEEE numbers in ANSI C + IEEE 754:
> #define minus_0 (-0.0)
> #define infinity (1e300*1e300)
> #define NaN1 (infinity-infinity)
> #define minus_infinity (-infinity)
> #define minus_NaN1 (-NaN1)
These don't work. -0.0 is NOT a "minus zero"; it's identical to 0.0.
Assuming that 1.0e+300*1.0e+300 is not representable as a (floating-
pint) number, the behavior is explicitly undefined, and the implementation
is not obliged to produce a representation of "infinity" for it. Assuming
you had defined "infinity" properly, the remaining expressions lie outside
the scope of the C standard, and nothing obliges an implementation to do
what you appear to wish be done about them.
More information about the Comp.std.c
mailing list