Confused by UInt64

Question

The code snippet below demonstrates a problem I am having with with text IO and UInt64 type variables in Delphi XE2 recently re-installed from a recent ISO image file - the compile fails with an error message relating to a missing Text.ReadUInt64 function or procedure. If I replace the failing line with

  ReadLn(F,A);

then the program compiles, correctly writes

-1
18446744073709551615

to the text file, and then (as expected) fails on the second read with an EInOutError: "Invalid Numeric Input". Do I have a corrupt install or has someone failed to write a ReadUInt64 function? The only reference to ReadUInt64 that I can find in help is the following definition:

function ReadUInt64: UInt64; virtual;

in System.Classes.TBinaryReader.ReadUInt64. I'm not sure if this is the 'same' function or, if so, why it is virtual...

I am also a little confused by Help's reference to UInt64. It defines it as:

type UInt64 = Int64;

If this is correct, how does the compiler know to treat an UInt64 differently to an Int64 variable?

procedure TForm1.Button1Click(Sender: TObject);
var
  F : TextFile;
  A : Int64;
  B : Uint64;
begin
{
Compiler warns on following line with message:
[DCC Warning] Unit1.pas(32): W1012 Constant expression violates subrange bounds
}
  A := $FFFFFFFFFFFFFFFF;
  B := $FFFFFFFFFFFFFFFF;
  AssignFile(F,'test.txt');
  ReWrite(F);
  Writeln(F,A);
  Writeln(F,B);
  CloseFile(F);
  AssignFile(F,'test.txt');
  ReSet(F);
  ReadLn(F,A);
{
Fails to compile on following line with message:
[DCC Fatal Error] Unit1.pas(42): E2158 System unit out of date or corrupted: missing 'Text.ReadUInt64'
}
  ReadLn(F,B);
  CloseFile(F);
end;

score 5 · Accepted Answer · edited Mar 19 '13 at 22:19

5

See QC102876. This is a known bug, reported as Text.ReadUInt64 missing, with the description:

The compiler generates a call to Text.ReadUInt64, when an UInt64 should be read from a stream. The linker, however, complains that Text.ReadUInt64 is missing.

This issue (bug) is resolved in XE3 (build #17.0.4625.53395), according to QC.

edited Mar 19 '13 at 22:19

Ken White

123,280
14
225
444

answered Mar 19 '13 at 22:06

LU RD

34,438
5
88
296

1

Without some info here, this isn't an answer. It becomes meaningless if the link to QC is moved or unavailable (which happens rather frequently, unfortunately). Can you add some detail from the QC report here so that there's info here in the answer? As is, this should be flagged as a link-only answer to an off-site location, which usually results in the moderators deleting it. :-) – Ken White Mar 19 '13 at 22:11
@KenWhite, I added all information there was. It's a pure bug in the RTL and it is fixed. The OP's code is as good as the one in the QC report to expose the bug. – LU RD Mar 19 '13 at 22:15
2

I added a slight bit more info, and block-quoted the citation from the bug report. The extra info makes it more useful for someone in the future who finds this with a search, but can't for some reason get to the QC site. Thanks (and +1). :-) – Ken White Mar 19 '13 at 22:20
1

Thanks for the bug confirmation. I have a work-around, but was interested in confirmation if it was 'my fault' or 'their fault'. – Penguino Mar 19 '13 at 23:13

Confused by UInt64

1 Answers1