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

[Jonas Maebe]

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