🚀 go-pugleaf

In article <1990May29.193451.6533@twinsun.com> eggert@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.