Questions about NCEG

Doug Gwyn gwyn at smoke.BRL.MIL
Mon Jun 4 06:11:14 AEST 1990


In article <1990May31.223436.23066 at twinsun.com> eggert at twinsun.com (Paul Eggert) writes:
>But in a normal implementation, one would expect the ANSI C types
>float and double to stand for IEEE 754 single format and double format,
>and the ANSI C unary floating `-' operator to stand for the IEEE 754
>`-x' function.

I totally disagree with the entire argument.  I would rather "double"
be what in Apple-speak is denoted as "extended", and certainly in many
discussions on the subject in X3J11 meetings, even the proponents of
IEEE floating point agreed that such a choice is intended to be
entirely up to the implementor (perhaps in consultation with his
customers).  It is utterly fantastic to expect a one-to-one
correspondence between operators/functions in the high-level language
and low-level machine operations; in fact even for integer operations
such a correspondence is seldom realizable.

>However, if we don't all agree on this question, shouldn't it be
>addressed by NCEG?

What NCEG can reasonably address about this is the specification of
extensions to provide programs access to some of the IEEE FP warts,
or provision of a separate specification that, taken in conjunction
with the C standard, would constrain the C implementation to follow
rules such that the ones you say would be "expected".  (However, I
personally would hope that they do not insist on IEEE FP for
whatever standard might result from their work.)

>While we're on the subject, NCEG should provide for a way for a program to
>print a number so that it can be read back.  ANSI C's "C" locale requires
>that an IEEE 754 implementation's scanf() cannot read some numbers that
>its printf() should be able to output, namely infinities and NaNs.

No, any use of NaNs and Infinities lies in the realm of undefined or
implementation-defined behavior, and thus is not constrained by the
C standard.  Certainly NCEG could consider imposing additional
requirements on printf()/scanf() in an optional, supplemental
standard that might result from their deliberations.



More information about the Comp.std.c mailing list