fixed bug in Reals.Mod which was actual on x86_64

without prototype, return type of ecvt was int, which has 4 byte size on
x86 but still has the same size on x86_64, that's why pointer which is 8
byte long could not fit in the variable holding return value. And it
could get negative value causing programs to explode. Fixed with casting
the result to LONGINT.


Former-commit-id: 0d85205cfd
This commit is contained in:
Norayr Chilingarian 2014-09-19 00:28:51 +04:00
parent 4a77f04720
commit ca407472a0
8 changed files with 12 additions and 14 deletions

View file

@ -3,10 +3,9 @@ MODULE Reals;
IMPORT S := SYSTEM;
(*
PROCEDURE -ecvt (x: LONGREAL; ndigit, decpt, sign: LONGINT): LONGINT
"ecvt (x, ndigit, decpt, sign)";
*)
"(LONGINT)ecvt (x, ndigit, decpt, sign)";
PROCEDURE Ten*(e: INTEGER): REAL;
VAR r, power: LONGREAL;
BEGIN r := 1.0;
@ -65,7 +64,7 @@ MODULE Reals;
d[k] := CHR(i MOD 10 + 48); i := i DIV 10; INC(k)
END
END Convert;
(*
PROCEDURE ConvertL*(x: LONGREAL; n: INTEGER; VAR d: ARRAY OF CHAR);
VAR i, k: LONGINT;
BEGIN
@ -74,8 +73,7 @@ MODULE Reals;
d[k] := CHR(i MOD 10 + 48); i := i DIV 10; INC(k)
END
END ConvertL;
(* (*commented because ecvt returns smth strange on x86_64, may be types must be checked, but anyway, getting rid of libc dependency is good *)
*)
PROCEDURE ConvertL*(x: LONGREAL; n: INTEGER; VAR d: ARRAY OF CHAR);
VAR decpt, sign, i: LONGINT; buf: LONGINT;
BEGIN
@ -86,7 +84,7 @@ MODULE Reals;
i := n - i - 1;
WHILE i >= 0 DO d[i] := "0"; DEC(i) END ;
END ConvertL;
*)
PROCEDURE Unpack(VAR b, d: ARRAY OF S.BYTE);
VAR i, k: SHORTINT; len: LONGINT;
BEGIN i := 0; len := LEN(b);