IEEE-754/ANSI-C "binding"

[Doug Gwyn (VLD/VMB)]

It's not clear to me what IEEE-754 "has infinity for", but it could be
as an accurate representation of the result of the operation n / 0 for
numbers n > 0, not necessarily as a means of representing overflow.

I think it is very important to realize that IEEE-754 is primarily a
"representational" standard and that the C standard operates at a higher
level that allows considerable latitude as to representation of the
values associated with data types.  One important consequence of this
difference in level is that the C numerical programmer CANNOT reliably
depend on low-level behavior of the representation, for example whether
or not x += 0 can always be compiled into a true no-op.  The C standard
is supposed to be compatible with underlying use of IEEE-754 data
representations and efficient use of IEEE-754 hardware implementations,
except for a deliberate decision about setting errno in some cases, but
it was not thought reasonable to require C implementations to provide
the same detailed access to all "features" (signalling NaNs, etc.) of
IEEE-754, any more than it was thought that the C programmer should be
able to exploit every single op-code in the unerdlying instruction-set
architecture.  It is NATURAL that the implementation choose some subset
of all possible hardware behavior to provide a well-defined, useful
realization of the high-level language.

A specification of (Std C + IEEE-754) can of course impose tighter
constraints on an implementation than just (Std C), but I don't think
it is wise to attempt to go much farther than, say, requiring that 1/0
produce a well-defined result (thus defining what (Std C) would call
"undefined behavior" for this situation) and other such exploitation of
flexibility (Std C) already gives implementations.  In particular, it
is a grave mistake to try to provide the entire gamut of low-level
choices in NaN behavior etc. at the level of C applications programming.
It is also unwise to attempt to dictate tight constraints on possible
optimizations by the language translator; inherent in the C language
definition all along, and reflected in the negotiated C standard, is
the notion that certain mathematically correct equivalences can be
exploited to optimize code generation.  We had to add qualifiers such
as "volatile" to the language to support application control over such
levels of optimization; in the absence of such explictly programmed
constraints, it is expected and desired that the compiler produce
underlying code that is somehow "better" than a naive literal
translation of the original source code.  Despite claims one sometimes
hears, C is not intended to be a structured assembly language, but a
genuine high-level language in which there need not be a clear, simple
one-to-one mapping from source code constructs to object code
instructions.  (The fact that certain knowledge about details of this
translation were exploited in writing device drivers etc. for specific
implementations does not contradict the fact that the linguistic
specification did not try to nail down such aspects of the translation.)