jacob navia said:
Obviously there will be implementations of C where the machine has no
floating point unit. In those machines, maybe this thing can
be skipped.
On a machine with no floating point unit, a conforming C
implementation must emulate FP in software. Floating point support is
not optional, even for standalone implementations. An implementation
that doesn't support floating-point is no more conforming than one
that doesn't support structs or arrays.
But it's good that the standard provides a description of how FP
overflow is to be handled for implementations that choose to do so.
The standard explicitly states that conversion to a floating-point
type invokes undefined behavior if the value cannot be represented in
the target type. And C99 6.5p5 says:
If an _exceptional condition_ occurs during the evaluation of an
expression (that is, if the result is not mathematically defined
or not in the range of representable values for its type), the
behavior is undefined.
(This doesn't apply to unsigned types, since reduction modulo 2**N is
part of the operation, so formally speaking the overflow doesn't
happen in the first place.)
[...]
It is a pity that the standard did NOT specify what happens with integer
overflow, even if indirectly acknowledges that the operation results
in undefined behavior.
Did you mean "directly" rather than "indirectly"?
Well it is missing the specifications of WHAT HAPPENS in case of integer
overflow.
My point is that the standard *explicitly* says that the behavior is
undefined for integer overflow. See C99 6.5p5, which I quoted above.
It's not a major point; if the behavior were merely undefined by
omission, it would mean exactly the same thing.
Floating point is optional. I have seen many implementations of C
(and done several with the embedded versions of my compiler system)
where there wasn't any floating point at all!
Such implementations are non-conforming. That's not necessarily a bad
thing; they might be quite useful. (Similarly, I've heard of
not-quite-C implementations where int is 8 bits.)
But IF there is floating point, it must be implemented along the lines
of the standard.
Yes, but some of the floating-point stuff in the standard is
mandatory, and some of it is optional. In particular, a conforming
implementation *must* support float, double, and long double, but it
*needn't* support Annex F:
An implementation that defines __STDC_IEC_559__ shall conform to
the specifications in this annex.
Now, why they didn't do the same for the integer exceptions (division by
zero, overflow) it is a mystery.
In general C99 advanced the language in floating point with very good
specifications, (environment, complex numbers) but left essential stuff
like integer overflow unspecified.
Mandating some particular behavior for signed integer overflow would
have had a significant performance impact on many systems.
IMHO it wouldn't have been a bad idea to specify an *optional* set of
behavior for signed integer overflow, similar to what was done for
floating-point. But if the committee had tried to require overflow
checking unconditionally (banning, for example, the common wraparound
behavior on 2's-complement systems), the standard would have had even
greater acceptance problems that it's actually had.
If you want to argue that the standard should mandate signed integer
overflow checking anyway, feel free to do so in comp.std.c.
