Euphoria on 32-bit machines has a problem. We use 64-bit values on a 53-bit number language. Now numbers like -1, which as a signed 64-bit number is 0xffff_ffff_ffff_ffff. You can poke -1 with poke8, but that number is actually a 32 bit value so no problem. You can even poke values such as 0xffff_ffff_ffff_f800 with poke8 on a 32-bit system. As soon as you employ things like numbers that cannot be represented in a double exactly, the number in the backend becomes 0.
The difference is if the number you use cannot be represented exactly in a eudouble, then the value becomes zero before it gets a chance to be written to memory.
The user has to avoid this kind of thing. It rather makes sense not to allow you to write a number when the value is imprecise. At the same time, writing 0 rather than what the user supplied is just wrong. It seems to be that this should be an error condition. It must be documented and caught by the backend.
This was fixed in 1110bd29c7d4, as a fix for ticket 931. It turns out the literal representation of the maximum 64-bit value was being interpreted as 264, which is actually one bigger than the biggest number representable in an unsigned long long. Literals and values approaching this value also get rounded up to 264 and didn't compare as smaller than the limit because it was equal to our limit. Then the casting of the eudouble to a 64-bit integer was set to 0 as an error condition for it was out of bounds. Leaving us with a 0 in memory.
GitHub