[SOLVED] TimeStampToMSecs function returns an invalid value on win32
lazarus / 64-FPC development

----------------------------------------------------------------------
korba812 · 2024-04-22 14:56

I just updated the win32 compiler (trunk) and noticed that timestamp
database fields are incorrectly displayed. After analysis, the problem
is TimeStampToMSecs function, which returns an invalid value. However,
if I modify this function and use a constant cast to Int64 type then
function returns correct value.

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i program
Project1; uses  SysUtils; // from Sysutils.TimeStampToMSecsfunction
TimeStampToMSecs1(const TimeStamp: TTimeStamp): Int64;begin  result :=
TimeStamp.Time + timestamp.date * msecsperday;end; function
TimeStampToMSecs2(const TimeStamp: TTimeStamp): Int64;begin  result :=
TimeStamp.Time + timestamp.date * Int64(msecsperday);end; var  TS:
TTimeStamp = (Time: 40811000; Date: 738998); begin 
WriteLn(TimeStampToMSecs1(TS));  WriteLn(TimeStampToMSecs2(TS)); 
ReadLn;end. 
Where does the problem lie? Compiler bug or lack of casting in the
TimeStampToMSecs function?

----------------------------------------------------------------------
alpine · 2024-04-22 15:39

Quote from: korba812 on April 22, 2024, 04:56:25 pmWhere does the
problem lie? Compiler bug or lack of casting in the TimeStampToMSecs
function?

Arithmetic overflow into the first one. Obviously it is the casting.

BTW, compiler gives a hint:
project1.lpr(9,10) Hint: Converting the operands to "Int64" before
doing the add could prevent overflow errors.

----------------------------------------------------------------------
korba812 · 2024-04-22 16:23

Ah, now I see. I just checked the stable release sources and there
TimeStampToMSecs function returns a value of comp type. In trunk it
has been changed to Int64 and indeed requires a cast. I will report
this in the bugtraker.

..edit..

The problem has already been solved in trunk, and I accidentally use
old sources... Sorry for the noise.