Jonas Maebe a écrit :
On 15 Aug 2007, at 03:51, mm wrote:
To J.M.
-------
You said "To be compatible with Delphi". With its current behaviour,
FPC 2.1.4 is not compatible with Delphi (and no more with FPC 2.0.4).
It is at least more compatible with Delphi than 2.1.4
Which Delphi? :-)
You quoted the bug #8321. There, I see two problems but none concerns
the subtraction of unsigned integers.
The a, b and 256 below are all unsigned integers. a+b gets a result type
of cardinal.
I don't agree. If you don't explicitly write Longword(256), by default,
it is a Longint.
1) The problem in the bug report.
"Edit1.text:=(intToStr(a + b - 256));".
Calling an overloaded function with a value whose type is not
clearly defined (a and b are bytes but 256 is not) is, at least,
dangerous programming.
Not necessarily.
Such behaviour is totally confusing. And not only for the compiler but
also for the programmers. At first glance what is the type of "a + b -
256"? It should be a Longint but, in fact, I don't know what it is. When
I see things like this, I don't know what the programmer wanted to do.
The only thing I can do is to suppose.
2) The problem in FPC.
For some reasons, FPC decided to call IntToStr(Int64) (here, Delphi
called IntToStr(Longint)). But, instead of extending the parameter as
a signed number, it extended it as an unsigned one. This is not
coherent. Since FPC selected a signed parameter overload, it should
have extended the parameter with
mov eax, param
cdq
not with, as it did,
mov eax, param
mov edx, 0
No. Whether you sign or zero extend depends on the "signdness" of the
source type, not of the target type.
That's not what I said. Where does the target type comes from? This is
the compiler choice. Why did the compiler select the signed parameter
overloaded function? Because it regarded the parameter as being a signed
integer [*]. What is this parameter if it is not what you call the
'source type'?
[*] Yes, this is logical. What is not logical is to believe that it
calls the signed parameter overload whereas it regards the parameter as
an unsigned one (and, if I understand you well, that exactly what FPC
does).
The whole point of using int64
rather than longint or dword is that it can represent all values from
low(longint) till high(cardinal) without any problem. If you "sign
extend" a cardinal into an int64, all values between high(longint)+1 and
high(cardinal) are going to become negative, which is wrong.
But you are saying this as if it was ok to regard "a + b - 256" as a
Longword. It is not at all. FPC should regard "a + b - 256" as a
Longint, not as a Longword. Moreover, assuming FPC regards "a + b - 256"
as a Longword, then it should call IntToStr(Qword), not IntToStr(Int64).
mm
http://www.ellipsa.net/
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
