[fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Feb 28 23:43:08 CET 2014

On 28 Feb 2014, at 21:07, Ewald wrote:

> On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
>> All hexadecimal constants are (conceptually) parsed as int64, so this is by design. int64($00000000ffffffff) is not -1.
> So all numeric constants that are not floats are parsed as Int64's?

They are parsed as the smallest integer type that can represent them. Because of the (unPascalish) decision to have an unsigned version of the largest supported integer type, there are indeed some cases that require decisions to define the behaviour and regardless of what decision you make, some people won't like it.

> Isn't that view about numeric constants a bit limited (why an Int64 for example, you could've picked a virtual Int256 just as well)?

Supporting larger constant values in the compiler than what we support in the language itself would be very counter-intuitive.

> Especially if you have a data type that can contain the number in it's original intention?

Hexadecimal numbers have no "intention" as far as signedness is concerned. How they are interpreted is up to the language definition.

> Delphi compatibility I read in the bug report you mentioned, and I understand that in mode delphi (see below though for a bit of `issues`), but the example program is in mode fpc (or how is it called?). Can that at least be called a bug (in the documentation at the very least)?

No, unless the documentation states that the behaviour is different for mode fpc. The behaviour, in both FPC and Delphi modes, is by design.

> By the way, what do you do when you want to port fpc to a one's comlement machine (if they still exist)? Is $FFFF FFFF FFFF FFFF equal to 0 then?

The internal representation of a machine is unrelated to how values in the source code are interpreted. Just like 'a' in an ASCII source file will always mean the character 'a', even if that source file is compiled for a machine that uses EBDIC. Numbers in FPC source files will always be interpreted as two's complement.

> And when you have a CPU that has a native integer size of 128 bit, how do you do the transformation then? Just truncate the constant to a 64 bit wide integer? Admitted, it are rare cases...

If FPC is ever ported to such a machine and if a built-in integer type of 128 bit would then be added for constants (the second would not automatically follow from the first), then the behaviour /might/ change. Just like it did from Turbo Pascal to Delphi ($fffffffff is interpreted as -1 in TP, but as high(cardinal) in Delphi). Such a change would probably be done based on a modeswitch, rather than by default in all syntax modes.


More information about the fpc-devel mailing list