 |
lua-l archive |
|
|
||
|
On 03/07/2014 09:14 PM, Roberto Ierusalimschy wrote:
That is actually one of the main reasons for my post. To share our experience and findings, so the next one searching the list will find our solution.When a value of floating type is converted to integral type, the fractional part is discarded. If the value of the integral part cannot be represented by the integral type, the behavior is undefined. /23/[...]Looks clear-cut to me ... PhilippOh well, then I looked at the wrong place. So the behavior is undefined, this means the P2020 is doing nothing that isn't allowed here, and maybe the code in the vanilla Lua source should be changed accordingly. We were surprised that only we encountered the problem. I haven't found anything on the list about it.Your system is correct, Lua is wrong. But we had never before met a system that actually raises an error (so, there is nothing about that on the list); we were a little over-confident with the code ("always work").
Believe me, we have made some learnings with our code as well while running code that was supposed to be portable on different PowerPC processors.Be aware that it is not easy to have a correct code that is also efficient and portable (in particular, that works with both 32 and 64-bit integers).
As you mention Lua 5.3: I haven't look too much into it, but if all double to in conversions go through "luaV_numtointeger" it seem to be safe for this problem. So far I am still planning to switch to 5.3 once it's released, so I am looking forward to that.(This is a "subliminial" reason for integers in Lua 5.3. Although this problem is rare, we are aware that there are several details not very clear in Lua about the conversion between floats and integers (e.g., how rounding is done), and that conversion is quite frequent at the C API. In Lua 5.3 all that stuff is much more clear.) -- Roberto
-- Thomas