[fpc-devel] Bug #0021641: Array of const gives check range error
jonas.maebe at elis.ugent.be
Wed Apr 4 11:23:36 CEST 2012
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
>> 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.
More information about the fpc-devel