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

[Ewald]

On 01 Mar 2014, at 18:17, Jonas Maebe wrote:

> 
> On 01 Mar 2014, at 01:19, Ewald wrote:
>> 
>> 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.

Talking about principles:
If hexadecimal is actually used to represent bit patterns (as Hans-Peter Diettrich wrote), then the decision to use a signed type here seems to violate this (represent bitpatterns) principle, since the highest bit in a signed number has a different meaning than the other bits, where in a bitpattern all bits have equal meaning.

It seems like sticking to one principle (signed integer as much as possible) actually breaks another principle (bitpattern).


> 
> You do care about the signedness, because the only way to represent int64(-1) in hexadecimal is as $ffffffffffffffff.

And what about -$1? Or is that too far fetched?



> 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.

Yes, but this can all be solved by parsing the string and storing it with one extra MSBit (if there is a `-` in front of the constant it must be negative, otherwise it should be positive). This highest bit then reflects the sign. `-1` would then be $1 FFFF FFFF FFFF FFFF, whereas $FFFF FFFF FFFF FFFF would be $0 FFFF FFFF FFFF FFFF. It really is quite easy to store it like that and `fix` things [picking a fitting datatype] afterwards. Anyway, then you have got backwards compatibility to take care of, since there will be someone out there who's code actually depends on this behaviour.



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

That is circular reasoning.

--
Ewald