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

[Jonas Maebe]

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

> 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.

> 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.

> 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. 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.


Jonas