Annoying Bug in Compiler

General Help
1

This fails , when its valid at assignment

const
  All_Rights  = $7FFFFFFFFFFFFFFF;   { Bits 0-62 set, bit 63 always 0 }

var 
  I : Int64

I := All_Rights  <---- Expected nativeint, got double

So does this - at the declaration

  All_Rights : Int64 = $7FFFFFFFFFFFFFFF;   { Bits 0-62 set, bit 63 always 0 }

I had to use this.

    All_Rights : Int64 = High(Int64);   { Bits 0-62 set, bit 63 always 0 }

Annoying as I am working with bits. I want a hex representation, that’s what my brain wants to see. Now, I have to trust the value of an obscure constant. And the rest of the bit definitions don’t visually relate to this declaration.

2

I was going to say use TBits from System.Classes, but astoundingly that only support 32bit integers.

I guess you could always get ai to knockup a nice class to make bit twiddling/representation easier.

3

I already have a class, so I could extend it.

I am using TMS webcore which converts to javascript. Unfortunately the library they have used is 32 bits. So I have a class that compiles in two forms - Using sets and 64 bits for Windows Server and using 2 X 32 bits and integers with methods called include, exclude for Javascript.

So the server uses sets to fiddle with it and JS uses the methods - for the same data in the same class.

4

Ah ok so that’s a TMS bug not delphi?

5

Hmm, you may be right. Now I have to try it in a pure delphi project

6

The Number type on Javascript only supports Integers up to ±(2^53 − 1). After that it automatically converts it to a Floating point number. It does have BigInt though that may be possible to use.

7

This is a little offside, but Delphi does have the unsigned uInt64 type that removes some of the awkwardness with the high bit that has been mentioned.

Regards
Pete