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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"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: 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)
  • Re: casting constant value from float to unsigned short - compiler bugs?
    ... the conversion that sparked this thread. ... floating to integer types "truncates towards zero". ... Since the C standard provides no ... truncation clause clarifies which one of the multiple definitions ...
    (comp.lang.c)
  • Re: [xpost] a new C/C++ type that when overflow i see it
    ... The standard defines clearly what happens with floating point overflow. ... Obviously there will be implementations of C where the machine has no ...
    (comp.lang.c)