The following is related to bug #0021641 (Array of const gives check range error).

Is it correct for the exception to manifest itself in the dword case and not the qword one?

   writeln(Format('%d', [qword(qword(High(Int64))+1)]));  //ok
   writeln(Format('%d', [dword(dword(High(integer))+1)]));  //exception

Stephano

Yes, it's correct, because as mentioned in the bug report tvarrec can hold a qword, but not a dword (and dword must be passed as 32 bit = longint for Delphi compatibility).

Jonas

Following the same logic, a qword must be passed as 64 bit = Int64 for Delphi compatibility, as Delphi's TVarRec can hold integer and Int64, but not qword nor dword.

In contrast, FPC's TVarRec can hold integer, Int64, and qword, meaning that a qword is passed as a qword and not Int64. So since FPC's TVarRec includes qword while Delphi's does not, why not add dword as well?

Stephano

patspiper wrote on Wed, 04 Apr 2012:

In contrast, FPC's TVarRec can hold integer, Int64, and qword, meaning that a qword is passed as a qword and not Int64. So since FPC's TVarRec includes qword while Delphi's does not, why not add dword as well?

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?

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe wrote

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.

Best regards,
Paul Ishenin

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?

Paul Ishenin wrote on Wed, 04 Apr 2012:

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

That explanation sums up well the dilemma.

IMHO, having Arrays of const that include Dword or Qword variables or constants result in a warning would be a good compromise in addition to documenting the incompatibility.

Stephano