Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-11

Double and LongWord

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Carsten Bager

Hi
This Function works on Intel platforms but when compiled to Arm (Linux) the right side is calculated as a LongWord.

Const
  cSecondsPerDay=86400.0;
  cTimeDate2UnixFiledateStart=25569.0;
  cUnixFileDateDateTimeStart=cSecondsPerDay*cTimeDate2UnixFiledateStart;
Function UnPackUnixTime2DateTime(UnixTime:LongWord):TDateTime;
Begin
  UnPackUnixTime2DateTime:=(UnixTime+cUnixFileDateDateTimeStart)/cSecondsPerDay;
End;

---

If I change the line to

UnPackUnixTime2DateTime:=(UnixTime+Double(cUnixFileDateDateTimeStart))/Double(cSe
condsPerDay);

It works

I am not sure if this is an error or not, but al previous compilers I have worked with, change to real calculation on the right side when constants included, is defined as real constants.

---

What do you think?

The compiler used is
Free Pascal Compiler version 2.6.2 [2013/07/16] for arm Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for ARM

Regards
Carsten

Jonas Maebe
to Carsten Bager
Carsten Bager wrote 15 lines
This Function works on Intel platforms but when compiled to Arm (Linux) the right side is calculated as a LongWord. Const cSecondsPerDay=86400.0; cTimeDate2UnixFiledateStart=25569.0; cUnixFileDateDateTimeStart=cSecondsPerDay*cTimeDate2UnixFiledateStart; Function UnPackUnixTime2DateTime(UnixTime:LongWord):TDateTime; Begin UnPackUnixTime2DateTime:=(UnixTime+cUnixFileDateDateTimeStart)/ cSecondsPerDay; End;

On all platforms the compiler will evaluate this expression using single precision, because all used floating point constants fit in single precision. The x87 is however limited in the sense that it can only perform calculations using extended precision, so you won't notice it there. You should probably also typecast cUnixFileDateDateTimeStart to double precision because otherwise you may encounter overflows if UnixTime is too large.

Jonas