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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
