lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 03/07/2014 09:14 PM, Roberto Ierusalimschy wrote:
   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 ...

Oh 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

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").
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.

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).
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.

(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

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.