Re: literal 9223372036854775808 is negative
- Posted by jimcbrown (admin) in May
- 525 views
Windows Calculator does the same thing.
Select Programmer mode and enter 1 << 63 you get -9223372036854775808.
Of course the calculator is using an int64 rather than a uint64 (in programmer mode, that is, IEEE-754s everywhere else).
Similar to what OE does, down to the int64 (integer) and long 80bits double (atom) parts.
I seem to recall but could be imagining this, when it finds a decimal point or when things get too big it simply discards
the int it's been building and starts again in a float. Maybe it is only #8000..,
Speaking of which, we found (some time ago) specifying the exact same value as #8000000000000000 works fine, as does
specifying it as 9223372036854775808.0 (!) or power(2,63).
I think you've hit the nail on the head here. If we hit a case that causes the parser to construct as a long double (or a library call in the case of power) then it stores the value correctly as a positive number.
However, if we have a code path that sticks only to integers, then it ends up overflowing to negative.
Plus I think I fully understand the issue now, just not where the bit of code going wrong is, point me at it if you need help.
I think it's not that straightforward. In my mind the issue here is that the parser in general would need to be able to detect when overflow happens, and automatically promote from integer to atom in those cases.
Matt Lewis did something similar way back on autopromoting from integer to atom when we want to add a delete_routine to a value that'd otherwise be fine to be stored as just a plain integer.
Only, this would be harder as it was fairly simple to detect when delete_routine was invoked and do that promotion in one place, but we might need to throw this overflow checking all over the place in the parser to catch it reliably.
This may not be the Euphoria bug we think it is.
Hence it is the Euphoria bug I think it is.
Debatable... on the one hand, Pete's POV seems the more user friendly one. But to back up Greg's POV, it might end up being a huge amount of work to fix up the issue and afterwards the overall behaviour might still be considered to be inconsistent (e.g. if overflow happens in machine code or a C dll that gets called).
LOL. I must be biased because Phix gets it right....
Wonder what Phix does differently, and if that's an easy thing to copy over into OE.
I am going to push a bit harder on this now, because we've just spent a frustrating four weeks trying to figure out the
best way to deal with(/gloss over) this[DONE], when of course the proper thing would be to get it fixed.
I mean, there are other workarounds. Adding a preprocessor that appends all literal integers in the source code with a ".0" so they are promoted by the parser into atoms is one idea that comes to mind.
