need i say more, try it. This is the case for RB 2012r2.1 as well as xojo 2013r3.3
it’s hard to believe such a fundamental bug has persisted for so long
NB: you need to use CLong() to work around this, but of course my app is peppered with val() so I keep stumbling over this bug.
p.
Not a bug. Val returns a double. A double has 53 bits of precision. Your number takes 54. Bottom line, using Val with Int64 is incorrect code.
that’s what i figured in the end, but it’s very misleading because you have to estimate at what degree of precision (ie how many digits) val will fail. so in essence, use val for fractional numbers and CLong for integers? Always?
You’d never know this from the LR and perhaps this should be pointed out there. CLong is not even referenced in the See Also under val.
Use Val/Cdbl for Integers and CLong for Int64. You’re right, the documentation is a bit sparse and should be improved. File a Feedback report against the documentation.
The “bug” is that RB does not raise an exception when the value is out of range or if a calculation overflows. But many, including Xojo, does not consider this a problem, sadly.
See also:
I can see your point with integer variables, but I don’t think it applies in this case. The whole point of a double is to get a reasonable approximation of very large (or small) numbers. Besides, how would you indicate “overflow”? There are much larger values that can be expressed exactly in a double, while others cannot. You’d have to count the number of bits required.