[fpc-pascal] About the bug report #9408...

[mm]

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/