[fpc-devel] Bug #0021641: Array of const gives check range error

[Jonas Maebe]

Paul Ishenin wrote on Wed, 04 Apr 2012:

> 04.04.2012 17:08, kyan ???????:
>>>> Delphi doesn't support qword at all, so there is no Delphi behaviour to
>>>> be compatible with in that case. Or at least it didn't when the above
>>>> was implemented. Does it now?
>>>
>>>
>>> No, it does not.
>>
>> Delphi XE has a UInt64 type. From the documentation:
>>
>> UInt64 represents a subset of the whole numbers. The range for the
>> UInt64 type is from 0 through 2^64-1. The UInt64 format is unsigned
>> 64-bit.
>>
>> Therefore it is equivalent to FPC's QWord type.
>
> The question was about TVarRec structure, was not it?

Yes and no: the reason we don't have a dword/cardinal field in tvarrec  
and therefore automatically typecast dword/cardinal to longint when  
passing them to an array of const, is because Delphi doesn't have a  
dword/cardinal field in tvarrec either. Otherwise, Delphi code would  
break when compiled in FPC when passing dwords to tvarrec, since the  
called routine would expect the type to be VTInteger, while FPC would  
mark it is VTDWord or so.

We did not have this problem with qword, because Delphi didn't support  
qword. However, if it does support qword now and nevertheless passes  
those values in the VInt64 field of tvarrec, then we have a problem:  
we have to choose between breaking backwards FPC compatibility or  
remaining Delphi incompatible. We cannot change it based on the  
compilation mode, because the "most likely correct behaviour" depends  
on the mode in which the called routine is compiled, not the caller  
(and we don't keep track of that, and I don't think we should either  
-- what syntax mode someone else wrote their code in is not something  
a programmer should have to care about).

I guess we'll have to document this as a known incompatibility.


Jonas