Re: Casting double to int produces inconsistent results from VS 2003 to VS 2008

"KD" <keith.degrace@xxxxxxxxx> wrote in message
news:18e21a9c-8a99-48a1-8744-1c07478b737d@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
I was expecting consistent results between VS2003 and VS2008. I
understand this is undefined behavior in the holy standard, but take
this bit from Stroustrup's FAQ: "Note that many "things" that people
refer to as "undefined" are in fact "implementation defined", so that
we can write perfectly specified code as long as we know which machine
we are running on. Sizes of integers and the rounding behaviour of
floating-point computations fall into that category." I thought maybe
numeric cast overflow fell into this category for MSVC.

You seem to misunderstand the note. Some things in the standard are
declared implementation-defined, e.g.

4.8p1 An rvalue of floating point type can be converted to an rvalue of
another floating point type. If the source value can be exactly
represented in the destination type, the result of the conversion is
that exact representation. If the source value is between two adjacent
destination values, the result of the conversion is an
implementation-defined choice of either of those values. Otherwise, the
behavior is undefined.

Others are undefined:

4.9p1 An rvalue of a floating point type can be converted to an rvalue
of an integer type. The conversion truncates; that is, the fractional
part is discarded. The behavior is undefined if the truncated value
cannot be represented in the destination type.

So, a behavior is either implementation-defined, or undefined. It's
meaningless to say "maybe the behavior is implementation-defined for
this particular implementation, even if it's undefined elsewhere."

In his note, Stroustroup simply points out that people in informal
conversations often lump undefined and implementation-defined behavior
together, even though there is a difference. Unfortunately, yours is not
the case of this mistaken identity, but an honest-to-God instance of
undefined behavior.

For completeness, here's the definition of the relevant terms:

1.3.5 implementation-defined behavior [defns.impl.defined]
behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation shall
document.

1.3.12 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct
or erroneous data, for which this International Standard imposes no
requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition
of behavior.

1.3.13 unspecified behavior [defns.unspecified]
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs.

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: Who can explain this bug?
    ... You're quick to castigate gcc! ... conform to the floating point accuracy requirements of the C standard, ... standard imposes so few accuracy requirements on floating point code. ... accuracy of the conversion between floating-point internal ...
    (comp.lang.c)
  • Re: Index register and accumulator
    ... exactly specified rounding, in decimal to match the real world of pounds ... The intent of the quanta parts of IEEE decimal is to permit automatic scaling, as binary floating point does, while preserving significance information. ... Loss of significance is detectable by the hardware in IEEE decimal, ... They had to make one important change to the COBOL standard, from mandating 34 digit precision to only 33-digit, so as to get something that would fit in a quad, but they were happy to do so to get the added range and be free from the task of explicitly coding the decimal point maintenance. ...
    (comp.arch)
  • Re: Sine code for ANSI C
    ... >> shell script) fully conforming. ... limits mentioned in the standard. ... adding a few more translation limits. ... minimal accuracy requirements for the floating point operations. ...
    (comp.lang.c)
  • Re: compression in floating point arithmetic
    ... If you want to force floating point values to the same type, ... I was thinking that the sequence point stuff could affect in some way this behaviour, it just seemed very reasonable reading the standard, even if not explicitally stated. ... showed me that in the other way the augmented precision can be carried out. ... Of course you don't need to explain to me the entire standard, there was just a specific point I thought it was saying that the truncation was forbidden, so for me it would have been enough that someone could explain me that in this case that point doesn't apply (like for example Jack did when he showed me that the contraction thing was wrong). ...
    (comp.std.c)
  • Re: Rfd: floating point truncation V1
    ... Some other standard I looked at makes "round towards zero" ... an internal representation of floating point negative zero, "-0E", which differs ... to go for an IEEE FP extension). ...
    (comp.lang.forth)