Hans-Peter Diettrich a écrit :
Marcel Martin wrote:
Unexpected overflows? The overflows occur or not according to
simple rules, perfectly defined, which ones depend on the types
of the operands.
Unexpected as depending on the values, not on the types. When the ranges
of the possible operands are known, it's also known whether an overflow
can occur in computations with these operands.
But overflows cannot be unexpected. If x is a Longword and
if x > 0, Inc(x,-1) will raise an overflow. And this is not
unexpected.
It is unexpected, for multiple reasons:
>
1) From online help in D4:
Inc(X) corresponds to the statement X := X + 1, and Inc(X, N)
corresponds to the statement X := X + N.
<<
I cannot see any correspondence, when one form produces overflows,
whereas the other form doesn't.
It shouldn't. Under the same circumstances, both have to
raise overflows. Here, it's not the overflow rules that are
inconsistent but the way they are implemented by such or
such compiler.
2) The overflow only occurs for special, machine specific conditions.
The writer of high level language code IMO can expect that no machine
specific details will influence the behaviour of his code, else the
compiler at least must issue appropriate warnings.
I agree. But what is the link with the fact that in no case
the compiler should code a "Inc(x,-1)" as a "Dec(x,1)"?
Since I don't have the current FPC compiler, I refer to D4 in this
(hopefully) last example:
This list is named "fpc-devel" ;-)
type
TCard = 0..1000; //or 0..$FFFFFFFF or 0..$8000
var
x: TCard;
const
c = -1;
begin
x := 5;
x := x + c;
Inc(x, c);
end;
Here no overflow occurs, at least not in D4.
No more with FPC. But with {$R+}, FPC will raise a range
check error if the resulting x is not in 0..1000. (For Delphi,
I don't know, it's too boring to get the generated assembler
code.)
An overflow occurs only in
the special case where the upper bound of the type is $FFFFFFFF, in
general when the highest bit in the highest byte of the memory
representation is part of the type. Would you call this an expected
behaviour?
Yes. Because I know that overflows only occur with 'native'
types :-)
IMO the inconsistent behaviour of the above code is a bug. I can accept
such behaviour only with respect to *full* Delphi compatibility,
This is the last reason for which I would accept. FPC has not to
follow Delphi and still less to be compatible with Delphi bugs.
(The future of Pascal is not Delphi, this is FPC ;-)
> where
every bug must be reproduced also by the FPC compiler. Otherwise I
expect a consistent and machine independent compilation and execution of
all high level language code.
From that point of view, FPC is incomparably better than Delphi.
Now, yes, maybe FPC developpers could add some code to check
overflows even for 'exotic' types. If you really need it, ask
them.
We have a big, BIG, communication problem...
I realized already that we are talking about different things :-(
I'm talking about computation in general, you're talking about machine
specific number representations and calculations.
We are talking about "Should the compiler replace "Inc(x,-1)"
by "Dec(x,1)?" The answer is no. And that's not because perfectly
defined overflow rules are not correctly implemented in Delphi
that this answer should change.
Please check your arguments with regards to unsigned types in general,
i.e. any zero-based integer type.
With your example? If the same rules would apply for both user
defined types and native types, in "x := x + c", the compiler
should regard c = -1 as c = 1000 (since the range 0..1000 is
the one of the residues modulo 1001). So "x := x + c" should be
coded as x := x + 1000 (or an error should be raised because -1
is not in 0..1000) and if x > 0, with {$Q+}, the operation
should raise an overflow. The same for "Inc(x,c)". (Notice that
with "Dec(x,1)", an overflow should occur only if x = 0 whereas
with "Inc(x,-1)" it should occur only if x <> 0. These two
instructions yield the same result but they don't get it the
same way and, thus, are not equivalent.)
mm
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
