Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!mips!bridge2!jarthur!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Questions about NCEG
Message-ID: <13039@smoke.BRL.MIL>
Date: 3 Jun 90 20:11:14 GMT
References: <13027@smoke.BRL.MIL> <13028@smoke.BRL.MIL> <1990May31.223436.23066@twinsun.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 37

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