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

[Jonas Maebe]

On 01 Mar 2014, at 01:19, Ewald wrote:

> On 28 Feb 2014, at 23:43, Jonas Maebe wrote:
> 
>> 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
> 
> That is perfectly true. But shouldn't the most basic behaviour of a language be at the very least intuitive?

It should be well-defined and consistent. One of Pascal's basic principles is that the native signed integer type is used for pretty much everything. While we (and Borland/CodeGear/Embarcadero) have extended the language beyond that (e.g. we support int64 on 32 bit platforms, and there's also the qword type), this principle is still followed as much as possible. In this case: constants are always preferably interpreted as signed numbers.

>> Hexadecimal numbers have no "intention" as far as signedness is concerned.
> 
> That's debatable (but, as you mention, classified as part of the language definition), but a constant has a certain magnitude. It is IMO this magnitude that is the point. I don't expect a number with a lot of digits (2**64 - 1) to become rather small in magnitude (1). That is what I mean by `intention`. With this I haven't said anything about signedness: I don't care if 762 is interpreted as a signed 32 bit integer or unsigned 16 bit integer, as long as the meaning remains.

You do care about the signedness, because the only way to represent int64(-1) in hexadecimal is as $ffffffffffffffff. Numbers in two's complement do no consist of a single sign bit followed by a magnitude. Those top 63 '1' bits together form the "-" sign in this number.

>> 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.
> 
> Here you have it: it might change.

Yes, indeed. I agree that's not ideal, but both the historical precedent (TP -> Delphi), current Delphi compatibility (it interprets hex numbers in the same way as FPC) and the general Pascal tradition (preferring signed over unsigned types) offset any hypothetical future inconvenience as far as I'm concerned.

> If the compiler doesn't find a fitting datatype for the constant, it should stop compiling and give an error IMHO


As mentioned before, for the compiler $ffffffffffffffff fits perfectly into an int64 because it parses it using val(str,int64var,value).


Jonas