Why doesn't raise overflow exception on multiplication example or how to detect in this case?
Why doesn't raise overflow exception on multiplication example or how to detect in this case?
{$RANGECHECKS ON} {$OVERFLOWCHECKS ON}
var
value: Int64;
begin
value := Int64.MaxValue;
value := value * 2; //doesn't raise exception
value := Int64.MaxValue;
value := value + 1; //does raise exception
{$RANGECHECKS ON} {$OVERFLOWCHECKS ON}
var
value: Int64;
begin
value := Int64.MaxValue;
value := value * 2; //doesn't raise exception
value := Int64.MaxValue;
value := value + 1; //does raise exception
Perhaps because *2 does a left-shift that doesn't trigger overflow conditions. Try value := value + value;
ReplyDeleteYeah, I see.. Very strange and serious that this bug remained for so many years in a product...
ReplyDeletePresumably it's fine in x64 because the compiler doesn't need to use these support functions.
ReplyDeleteYes @David, it´s fine in x64.
ReplyDeleteInterestingly, "Evaluate / Modify (Ctrl + F7)" raises the overflow exception in addition and multiplication operations in debug time.
Is it safe to assume the following? What do you think?:
if ((Abs(value) * 2) < Abs(value)) then
raise EIntOverflow.Create();
I'd fix it properly as Stefan indicated
ReplyDelete/interested
ReplyDeleteRSP-16617 has been fixed in 10.2 -- I know still pending status update. Can someone double check it?
ReplyDeletequality.embarcadero.com - Log in - Embarcadero Technologies
Marco Cantù I should have tried in 10.2 first and not in 10.1 which I was working in. ;)
ReplyDeleteSeems that issue was fixed altogether - llmulo looks kinda different. thumbsup
Also fixed in 10.2 list contains RSP-16617 but not the others from QC.
Stefan Glienke Are there two versions of llmulo? One with overflow checks, one without? I hope the overflow tests are switched at runtime.
ReplyDeleteI can‘t reproduce this. In Win32 and in Win64 it produces an integer overflow error (EIntOverflow) as expected. I I tried in Tokyo 10.2.3. Since I was the one who reported this, I checked this regularly and it was fixed a while ago (RSP-16617).
ReplyDeleteDavid Heffernan there is only one _llmulo. it returns the correct overflow flag. Depending on settings, the overflow flag is checked or ignored. As I said, the error does not occur in Tokyo 10.2.3 anymore, not in Win32 and not in Win64. Just checked this again.
ReplyDeleteSo this is much ado about nothing, if you ask me.
ReplyDeleteRudy Velthuis What's your point. The defect has been fixed so we shouldn't have been moaning before it was fixed??!!
ReplyDeleteRudy Velthuis I thought you were a dentist and not a necromancer ;)
ReplyDeleteDavid Heffernan my point is that a lot of fuss was made about how this problem was still not solved (shame, shame) when it was actually solved.
ReplyDeleteStefan Glienke I‘m afraid I don‘t get what you mean.
ReplyDeleteDavid Heffernan FWIW, the overflow tests are compiled in (directly after the call to _llmulo) or not, depending on settings.
ReplyDeleteRudy Velthuis The post is from over a year ago!!!
ReplyDeleteAh, I see. Then I apologize. I got here by a post from Jeroen Pluimers. I didn‘t know nor notice that he was discussing a year old post in his blog. Pffft!
ReplyDelete