Currently, Round and Trunc functions ignore the state of $OVERFLOWCHECKS compiler directive. The following code prints "-2 -2":

{$MODE OBJFPC}{$OVERFLOWCHECKS ON}
var
  a: Integer;
  b: Double;
begin
  b := MaxInt;
  a := Round(2.0 * b);
  Writeln(a);
  a := Trunc(2.0 * b);
  Writeln(a);
end.

This is Delphi-compatible.
However, I think this is a bug, even if Delphi-inherited, and should be fixed in fpc/objfpc mode.
What do others think?

Which arithemtic operation overflows? Fill a bug report, if you no range check error is thrown.

In Borland-speak, these are not overflow errors, but range errors. Turn on range checking, and you will get an error.

The difference between range and overflow errors is as follows:
* range errors occur when an implicit type conversion occurs from one type to another (e.g., when assigning, or when using it as a parameter), and the value is not legal for the destination type
* overflow errors occur when performing a mathematical operation on a value and the result cannot be represented in the type used for performing this operation (this "operation type" depends both on the target platform and the types of the operands)

Jonas

Yes, this works.

It is debatable whether "Round" is an operation or conversion, but I agree that this is a minor thing --
the important one is that there is a way to guard against overflows.

Round itself does not cause any error, as it returns an int64. It's the assignment of the result of round() to your longint variable that triggers the range check (error).

Jonas