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

_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to