Re: Casting double to int produces inconsistent results from VS 2003
to VS 2008
KD wrote:
On Mar 28, 10:09 am, peter koch <peter.koch.lar...@gmail.com> wrote:
On 28 Mar., 13:40, KD <keith.degr...@gmail.com> wrote:
On Mar 27, 10:56 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
KD wrote:
I am porting some legacy code from VS 2003 to VS 2008, and I've
encountered a problem. Here is an example to illustrate:
{
double f = 10000000000.0;
int d = (int) (f);
}
When I run from VS2003, I get:
d = 1410065408
When I run from VS2008, I get:
d = -2147483648
Can someone please explain why d2 is different in VS 2008?
The value of ten billion cannot be stored in an int. The Standard says
the behavior of the program in such a case is undefined. It was
undefined in 2003, it's still undefined in 2008. If the compiler
creators decide to define it somehow, they haven't documented it. At
least I've not seen anything particular. If you want to port undefined
behavior, you're on your own. If you want advice what to do now, I
would probably try to refactor this to remove undefined behavior.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Thank you, Victor. I am fishing for information about how MSVC in
particular handles it. I am hoping that they documented this
somewhere, along with a note about how they decided to handle it
differently somewhere between VS2003 and VS2008.
And thanks for the advice about refactoring. Unfortunately, like I
mentioned, this is legacy code which is actually very stable even with
its undefined behavior dependent code.
You are contradicting yourself: apparently, the code is not so stable:
if it were, it would still be working.
No contradiction. I meant stable on VS2003, not across versions of
MSVC. And by stable, I mean that the amount of issues being reported
for this module is very, very low. It has been in production for many
years now.
That's not the definition of "stable" used by most professional
programmers I know.
The least amount of changes I
have to make to this code, the better. I know that borders on
sacrilege for some people, but this is the real world for me. The
last thing I want to do is go on a refactoring bender and introduce a
whole new set of bugs. Anyway, that's a whole other discussion...
I really do not believe it should be such a big deal: apparently the
program had some specific expectations when converting huge numbers
from double to int. Replace those places with a function doing the
right thing and you're done.
/Peter
Introducing new bugs is a big deal to me, which is often what happens
when code changes. Especially old legacy code that I didn't write.
So, preexisting bugs are OK, then?
So I still stand by what I said: the least amount of changes I have to
make to this code, the better.
You don't *have to* make any changes. The bug was there, it's still
there now. Well, in light of that, you may *need to* make changes, but
by trying to introduce code to rely on the *undefined* behaviour that is
apparently different now (as all undefined behavioiurs go, nothing is
permanent), you're going to get two bugs for the price of one code
change: the old bug will still be there, and you'll have introduced
another one, by relying on something that will undoubtedly change in the
future, since there is no standard definition for what you're trying to
rely upon.
> In an ideal world, I would have posted
this message, and someone would have said, "Oh yea, such and such
changed in VS2005 but check out this compiler option to make it behave
like it did in VS2003". Unfortunately that did not happen.
Because it can't. Even in an ideal world the undefined behaviour is
undefined. Perhaps *your* ideal world is unlike everybody else's... :-)
About your refactoring suggestion. The phrase that sticks out in your
response is "doing the right thing". I'm still not confident what the
right thing is, since I can't find any documentation about it.
Take a copy of the Standard. Read [conf.fpint], that's all the
documentation there is. You need to fix the old bug you didn't know you
had. Or maybe you did know, but you chose not to do anything about it
then. (I am using a collective 'you', not personal: "you" as in the
group that released your product, with some people leaving and people
joining it the group identity is apparently still there, otherwise you,
now personally, wouldn't feel the need to do anything).
The Right Thing(tm) would be to fix the program by removing the cause of
the undefined behavior. You (personally or collectively) would need to
*decide* what the *correct outcome* of such conversion has to be, and
then code for it. Experimentation with the old compiler might help you
decide, but again, don't experiment with the new and then rely on what
*seems* to be its behaviour. It's *undefined*.
Without documentation, I would have to rely on experiments with the
compiler, which I think you would agree is not always the best idea.
Yes, we certainly agree. That's what your predecessor seems to have
done, and see where it got you.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask