mm wrote 10 lines
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.
Show quoted text 6 lines
> 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).
Show quoted text 21 lines
>> 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.
Show quoted text 5 lines
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.
Show quoted text 9 lines
> 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 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
