On 20 Aug 2007, at 00:56, mm wrote:
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? :-)
Mostly whichever Delphi the people who submit those bugs are using,
although most things are usually verified against Delphi 6.5 and/or 7.
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.
It is, but in case of an expression with only unsigned types and
positive constants., we convert everything to dword rather than
longint (because of Delphi).
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.
It is what you said, but apparently not what you meant.
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 [*].
No, because if you have to choose between these overloads:
sysstrh.inc:function IntToStr(Value: integer): string;
sysstrh.inc:function IntToStr(Value: Int64): string;
sysstrh.inc:function IntToStr(Value: QWord): string;
(this is compiled in objpas mode, so integer = longint), and someone
passes an expression which has been evaluated as cardinal, then you
prefer the int64 to the longint version because an int64 can
represent all cardinal versions, while a longint cannot. And the
compiler prefers an int64 to a qword because in general it prefers
signed over unsigned types (except when Delphi says otherwise).
What is this parameter if it is not what you call the
'source type'?
The source type is the type of the value/expression you pass to a
function. Based on all the source types of the parameter values/
expressions, we select the overloaded function to be called (the
closest match which preferably can handle all possibly passed
values). After this selection, all parameter values/expressions are
converted to the actual parameter types of this function.
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.
Delphi says otherwise. We used to regard that as longint, and then
the bug report came. We could of course implement umpteen different
kind of type evaluation rules depending on people's taste, but that
would be a lot of work both as far as implementation, maintenance and
testing is concerned (and it would make it even more difficult to
asses which type will be used based on looking at some source code).
Moreover, assuming FPC regards a + b - 256
as a Longword, then it should call IntToStr(Qword), not IntToStr
(Int64).
That may possibly happen if int128 ever becomes common place, because
in general the highest supported signed type is usually treated in a
special way.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
