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

[Ewald]

On 01 Mar 2014, at 03:06, Hans-Peter Diettrich wrote:

> 
> Numerical constants, where the sign matters, should only be encoded in decimal. The other formats (hex,oct,bin...) are intended for use with binary values, where the bit pattern is important. Then the code compiles correctly on any kind of machine.

Yeah, the only problem is that there are few calculators lying around here that can actually calculate the decimal value of $FFFF FFFF FFFF FFFF.

But you are right. If I use 18446744073709551615 instead of $FFFF FFFF FFFF FFFF, it appears to be right. This is again what I meant with unintuitive behaviour: 18446744073709551615 should be equal to $FFFF FFFF FFFF FFFF IMHO. Anyway, I've got this feeling that I won't be able to convince any compiler developer to fix this, so I will leave it at that. I'll fix my precompiler instead to handle this scenario for me.

> 
> Assumptions about type sizes and encodings can make *application* code unportable. E.g. the Extended type doesn't have a guaranteed size and binary representation,

That is true. But I don't make any assumptions about sizes of types. I use the name QWord because it happens to be largest possible unsigned integer in fpc, not because it is 8 bytes long. That is also why I started my example program with the 3 sizeof statements: to remove assumptions about datasizes.

> IIRC it's equivalent to Double on x64.

Nowp, Double is 8 bytes long whereas Extended is 10 bytes long on this machine. Then again it doesn't matter here. Replace `Extended` in the entire thread with `Double` and you still get the same bahaviour.

--
Ewald